linux-kernel - Re: [PATCH] rust: workqueue: define built-in bh queues

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: <Z7yrwkGlJZPC99uL@slm.duckdns.org>
Date: Mon, 24 Feb 2025 07:26:26 -1000
From: Tejun Heo <tj@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
	Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Wedson Almeida Filho <walmeida@...rosoft.com>,
	Nell Shamrell-Harrington <nells@...ux.microsoft.com>,
	Dirk Behme <dirk.behme@...il.com>,
	Konstantin Andrikopoulos <kernel@...dragore.io>,
	Danilo Krummrich <dakr@...nel.org>,
	Roland Xu <mu001999@...look.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: workqueue: define built-in bh queues

On Sat, Feb 22, 2025 at 12:57:03PM +0100, Miguel Ojeda wrote:
...
> Moreover, I do take issue with your social media post. You claim:
> 
>     "Rust kernel patches should really level up on commit messages and
> not merging random code with zero callers."
> 
> We do _not_ merge random code. In fact, my message above was Cc'ing
> workqueue precisely because we do not just randomly merge code.
> 
> Not just that -- if you had actually checked the Git log, you would
> have seen that Tejun himself merged the bulk of the content in that
> file. So it seems now you have just blamed two different subsystems
> entirely.
> 
> Regarding "zero callers": that is the usual rule, yes, but it can
> happen when there are expected users in the future, and in the end it
> is up to the judgement of the maintainers. For instance, in this file,
> there are other queues that do not have users yet.

FWIW, the commit message could be better but at the same time I'm not sure
commit message bar is any higher for C patches for something this trivial.
As for no-immediate-user policy, yes, generally true but again it's sometims
a necessity or just more convenient to merge these API patches separately -
e.g. features straddling across subsystems, straightforward prep patches and
so on. So, that's the *general* rule but rules without flexibility are often
silly things and it's not like culling these trivial wrappers afterwards is
difficult.

Thanks.

-- 
tejun