linux-kernel - Re: [PATCH] lockdep: introduce lockdep_assert_not

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]

Message-ID: <20190628122047.GG20977@suse.cz>
Date:   Fri, 28 Jun 2019 14:20:47 +0200
From:   David Sterba <dsterba@...e.cz>
To:     David Sterba <DSterba@...e.com>
Cc:     peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lockdep: introduce lockdep_assert_not_held()

On Thu, Jun 13, 2019 at 03:36:04PM +0200, David Sterba wrote:
> Add an assertion that a lock is not held, suitable for the following
> (simplified) usecase in filesystems:
> 
> - filesystem write
>   - lock(&big_filesystem_lock)
>   - kmalloc(GFP_KERNEL)
>     - trigger dirty data write to get more memory
>       - find dirty pages
>       - call filesystem write
>         - lock(&big_filesystem_lock)
> 	  deadlock
> 
> The cause here is the use of GFP_KERNEL that does not exclude poking
> filesystems to allow freeing some memory. Such scenario is a bug, so the
> use of GFP_NOFS is the right flag.
> 
> The annotation can help catch such bugs during development because
> the actual deadlock could be hard to hit in practice.
> 
> Signed-off-by: David Sterba <dsterba@...e.com>

Any comments on that? I just found another case with convoluted
callstacks where the lockdep assertion would catch the potential lock up
earlier than under the testing load.