linux-kernel - Re: [PATCH] workqueue: rust: add work item runtime modification support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2026020748-italicize-joyride-cb57@gregkh>
Date: Sat, 7 Feb 2026 08:55:21 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>
Cc: rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, Tejun Heo <tj@...nel.org>,
	Tamir Duberstein <tamird@...il.com>, Alban Kurti <kurti@...icto.ai>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: rust: add work item runtime modification
 support

On Fri, Feb 06, 2026 at 01:07:07PM -0800, Hamza Mahfooz wrote:
> On Wed, Feb 04, 2026 at 06:24:18AM +0100, Greg KH wrote:
> > On Tue, Feb 03, 2026 at 01:55:55PM -0800, Hamza Mahfooz wrote:
> > > This feature is required for our Hyper-V VMBus reimplementation effort.
> > > As it provides the ability to modify the running state of work items at
> > > runtime.
> > 
> > This is great, BUT we need to see the user of this new code at the same
> > time before adding it to the kernel tree.  Why not just submit this as
> > part of your patch series for the rust hyperv stuff?
> 
> I don't have the rest fully fleshed out quite yet. So, mostly just
> working on getting the prerequistes in a good state. I can mark it as an
> RFC if that is preferable.

Just send it all when you feel it is ready, no need to ask us to review
an api when you don't even have working code that uses it for you to
determine if it works or not :)

thanks,

greg k-h