linux-kernel - Re: [PATCH RFC 00/11] rust: Implicit lock class creation & Arc Lockdep integration

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, 18 Jul 2023 09:48:01 -0700
From:   Boqun Feng <boqun.feng@...il.com>
To:     Gary Guo <gary@...yguo.net>
Cc:     Alice Ryhl <aliceryhl@...gle.com>, lina@...hilina.net,
        alex.gaynor@...il.com, alyssa@...enzweig.io, asahi@...ts.linux.dev,
        benno.lossin@...ton.me, bjorn3_gh@...tonmail.com, daniel@...ll.ch,
        linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev, marcan@...can.st, masahiroy@...nel.org,
        nathan@...nel.org, ndesaulniers@...gle.com, nicolas@...sle.eu,
        ojeda@...nel.org, rust-for-linux@...r.kernel.org,
        sven@...npeter.dev, trix@...hat.com, wedsonaf@...il.com
Subject: Re: [PATCH RFC 00/11] rust: Implicit lock class creation & Arc
 Lockdep integration

On Sat, Jul 15, 2023 at 03:25:54PM +0100, Gary Guo wrote:
[...]
> > > I don't think the fallibility is an issue. Lockdep is a debugging tool, 
> > > and it doesn't have to handle all possible circumstances perfectly. If 
> > > you are debugging normal lock issues you probably shouldn't be running 
> > > out of RAM, and if you are debugging OOM situations the lock keys would 
> > > normally have been created long before you reach an OOM situation, since 
> > > they would be created the first time a relevant lock class is used. More 
> > > objects of the same class don't cause any more allocations. And the code 
> > > has a fallback for the OOM case, where it just uses the Location object 
> > > as a static lock class. That's not ideal and degrades the quality of the 
> > > lockdep results, but it shouldn't completely break anything.  
> > 
> > If you have a fallback when the allocation fails, that helps ...
> 
> I am pretty sure lockdep needs to do some internal allocation anyway
> because only address matters for lock class keys. So some extra
> allocation probably is fine...
> 

Lockdep uses a few static arrays for its own allocation, but doesn't use
"external" allocatin (i.e. kalloc() and its friends. IIUC, originally
this has to do in this way to avoid recursive calls like:
lockdep->slab->lockdep, but now lockdep has a recursion counter, that's
not a problem any more. However, it's still better that lockdep can work
on its own without relying on other components.

Regards,
Boqun