linux-kernel - Re: [PATCH 3/3] rust: miscdevice: adjust the rust_misc

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: <CAH5fLghKx9Z-Gn8z_rZfxSy8tTFkOza9KPhGawwLdDqHbTnFEA@mail.gmail.com>
Date: Fri, 24 Jan 2025 12:37:02 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Christian Schrefl <chrisi.schrefl@...il.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...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>, 
	Trevor Gross <tmgross@...ch.edu>, Arnd Bergmann <arnd@...db.de>, Lee Jones <lee@...nel.org>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] rust: miscdevice: adjust the rust_misc_device sample
 to use RegistrationData.

On Fri, Jan 24, 2025 at 12:22 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Fri, Jan 24, 2025 at 11:39:23AM +0100, Alice Ryhl wrote:
> > On Fri, Jan 24, 2025 at 11:34 AM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Fri, Jan 24, 2025 at 10:42:53AM +0100, Alice Ryhl wrote:
> > > > On Fri, Jan 24, 2025 at 9:06 AM Greg Kroah-Hartman
> > > > <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > On Fri, Jan 24, 2025 at 08:29:38AM +0100, Alice Ryhl wrote:
> > > > > > On Thu, Jan 23, 2025 at 6:57 PM Christian Schrefl
> > > > > > <chrisi.schrefl@...il.com> wrote:
> > > > > > >
> > > > > > > Hi Alice
> > > > > > >
> > > > > > > On 21.01.25 4:40 PM, Alice Ryhl wrote:
> > > > > > > > On Sun, Jan 19, 2025 at 11:11 PM Christian Schrefl
> > > > > > > > <chrisi.schrefl@...il.com> wrote:
> > > > > > > >>
> > > > > > > >> Share the mutex stored in RustMiscDevice between all instances using an Arc
> > > > > > > >> and the RegistrationData of MiscDeviceRegistration.
> > > > > > > >>
> > > > > > > >> This is mostly to Demonstrate the capability to share data in this way.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Christian Schrefl <chrisi.schrefl@...il.com>
> > > > > > > >
> > > > > > > > This change causes all open files to share the same value, instead of
> > > > > > > > it being per-fd.
> > > > > > >
> > > > > > > I know, if that is unwanted I'm fine with dropping this patch,
> > > > > > > it is mostly here to show how patch 2 can be used.
> > > > > >
> > > > > > Perhaps instead of changing the per-fd value, we could add a new
> > > > > > shared value? E.g., it could have a counter for the number of open
> > > > > > files.
> > > > >
> > > > > Counters don't work, sorry (think about dup() for file handles), please,
> > > > > either make it per-file handle, or a "global" thing for the specific
> > > > > object, don't attempt to count open/release calls, the vfs does this for
> > > > > us already.
> > > >
> > > > I mean, it's just for an example, shrug. It could also be another
> > > > ioctl that updates the shared value.
> > >
> > > Sure, but the number of times I've seen sample code copied into "real"
> > > code is way too high.  Also, getting people to stop thinking they even
> > > can count the number of open file handles is a good idea as that's an
> > > extremely common "anti-pattern" in way too many drivers even today (i.e.
> > > if you try to count open calls, or even restrict the number of open
> > > calls to attempt some sort of control, you're doing it totally wrong.)
> >
> > Fair point. Do you have good ideas for some data we could put in the
> > data shared by all instances of the file?
>
> "shared_cookie"?  Read/write and let readers and writers access it.  But
> I thought that was what the misc example did already, but I might be
> getting confused here, it's been a while since I looked at the code,
> sorry.

Makes sense to me.

The existing cookie is per `struct file`, but this series is about
making it possible to have data shared by all instances of a
miscdevice. But having two cookies, one that is per `struct file` and
one that is global makes sense to me.

Alice