From: Steven Rostedt <rostedt@goodmis.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Liam Howlett <liam.howlett@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michel Lespinasse <walken.cr@gmail.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2] mmap_lock: Change trace and locking order
Date: Tue, 7 Sep 2021 12:53:09 -0400 [thread overview]
Message-ID: <20210907125309.7af5cd19@gandalf.local.home> (raw)
In-Reply-To: <c2fc9aff-4275-3025-fced-83c0f69e69b1@suse.cz>
On Mon, 6 Sep 2021 17:00:18 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:
> On 9/3/21 04:21, Liam Howlett wrote:
> > Print to the trace log before releasing the lock to avoid racing with
> > other trace log printers of the same lock type.
>
> That description could use more details maybe?
Agreed, perhaps add something like this:
Due to the tracing of taking the mmap_lock happened outside the lock
itself, the trace can become confusing, making it look like more than one
task has the same lock:
task-749 [006] .... 14437980: mmap_lock_acquire_returned: mm=00000000c94d28b8 memcg_path= write=true success=true
task-750 [007] .... 14437981: mmap_lock_acquire_returned: mm=00000000c94d28b8 memcg_path= write=true success=true
task-749 [006] .... 14437983: mmap_lock_released: mm=00000000c94d28b8 memcg_path= write=true
When in actuality the following occurred:
task-749 [006] - take mmap_lock
task-749 [006] - trace taking of mmap_lock
task-749 [006] - release mmap_lock
task-750 [007] - take mmap_lock
task-750 [007] - trace taking of mmap_lock
task-749 [006] - trace releasing of mmap_lock
Although the mmap_lock was taken and released then taken again by another
process, the lack of protection around the tracing of the activity caused
it to show the events out of order. If the tracing of the taking and
releasing of the mmap_lock is done inside the lock, it will protect this
from happening.
Andrew, I see you took this into your tree. Not sure if you sent it to
Linus yet. Perhaps add the above to the patch if you have not yet sent it
(with Liam's permission of course).
Seeing that the patch has this as a link in the commit, at the very least,
the above explanation will be archived.
-- Steve
>
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> > Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
next prev parent reply other threads:[~2021-09-07 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 2:21 Liam Howlett
2021-09-03 10:55 ` Matthew Wilcox
2021-09-06 15:00 ` Vlastimil Babka
2021-09-07 16:53 ` Steven Rostedt [this message]
2021-09-07 17:57 ` Liam Howlett
2021-09-06 15:11 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210907125309.7af5cd19@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=walken.cr@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®