linux-kernel - Re: [PATCH 2/2] rust: block: fix wrong usage of lockdep API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zr50gxz8oH-mcuMq@boqun-archlinux>
Date: Thu, 15 Aug 2024 14:34:59 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Andreas Hindborg <nmi@...aspace.dk>,
	Jens Axboe <axboe@...nel.dk>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	"Behme Dirk (XC-CP/ESB5)" <Dirk.Behme@...bosch.com>,
	Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] rust: block: fix wrong usage of lockdep API

On Thu, Aug 15, 2024 at 07:15:43PM +0000, Benno Lossin wrote:
> On 15.08.24 21:05, Benno Lossin wrote:
> > On 15.08.24 10:04, Alice Ryhl wrote:
> >> On Thu, Aug 15, 2024 at 9:49 AM Andreas Hindborg <nmi@...aspace.dk> wrote:
> >>>
> >>> From: Andreas Hindborg <a.hindborg@...sung.com>
> >>>
> >>> When allocating `struct gendisk`, `GenDiskBuilder` is using a dynamic lock
> >>> class key without registering the key. This is incorrect use of the API,
> >>> which causes a `WARN` trace. This patch fixes the issue by using a static
> >>> lock class key, which is more appropriate for the situation anyway.
> >>>
> >>> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
> >>> Reported-by: "Behme Dirk (XC-CP/ESB5)" <Dirk.Behme@...bosch.com>
> >>> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/6.2E11.2E0-rc1.3A.20rust.2Fkernel.2Fblock.2Fmq.2Ers.3A.20doctest.20lock.20warning
> >>> Signed-off-by: Andreas Hindborg <a.hindborg@...sung.com>
> >>
> >> LGTM. This makes me wonder if there's some design mistake in how we
> >> handle lock classes in Rust.
> > 
> > So `LockClassKey::new` doesn't initialize the `lock_class_key` and is
> > also movable. I think in this case we either just overlooked it or
> > thought that the C side would initialize it.
> > 
> > For those people that know about this, are there APIs that initialize
> > `lock_class_key` themselves? (ie not a function to initialize a lock
> > class key, but rather an API like `__blk_mq_alloc_disk`)
> > Because if it is usually expected that the class key is already
> > initialized, then I think we should change our abstraction.
> 
> Sorry, I got confused, this has nothing to do with initialization.
> 

For static allocated key, no initialization is needed, for dynamic
allocated key, lockdep_register_key() will need to be called before
using the key.

Regards,
Boqun

> ---
> Cheers,
> Benno
> 
> > Additionally, I think that it needs to be pinned, since it contains an
> > `struct hlist_node` (I might be wrong on this, but that looks and sounds
> > like an intrusive linked list).
> > 
> > Also the `new` function is probably prone for misuse, since it will
> > create a new lock class key every time it is run. But as I learned in
> > [1], the more common use-case is a single lock class key for several
> > locks. Therefore it might be a good idea to at least rename it to
> > `new_dynamic` or similar and add appropriate documentation pointing to
> > `static_lock_class!`.
> > 
> > [1]: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/.E2.9C.94.206.2E11.2E0-rc1.3A.20rust.2Fkernel.2Fblock.2Fmq.2Ers.3A.20doctest.20lock.20warning/near/460074755
> > 
> > ---
> > Cheers,
> > Benno
> > 
> > 
>