linux-kernel - Re: [PATCH v2] mmap_lock: Change trace and locking order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 7 Sep 2021 17:57:48 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     Vlastimil Babka <vbabka@...e.cz>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michel Lespinasse <walken.cr@...il.com>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2] mmap_lock: Change trace and locking order

* Steven Rostedt <rostedt@...dmis.org> [210907 12:53]:
> On Mon, 6 Sep 2021 17:00:18 +0200
> Vlastimil Babka <vbabka@...e.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).

Yes, I agree this change is useful.

Let me know if you want a respin of the patch instead.

Thanks,
Liam

> 
> 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@...cle.com>
> > > Suggested-by: Steven Rostedt (VMware) <rostedt@...dmis.org>  
> > 
> > Acked-by: Vlastimil Babka <vbabka@...e.cz>
>