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

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

Message-ID: <85c74182-71e8-41de-b13c-05da5ceab04d@gmail.com>
Date: Fri, 24 Jan 2025 12:42:23 +0100
From: Christian Schrefl <chrisi.schrefl@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: 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 24.01.25 12:37 PM, Alice Ryhl wrote:
> 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.

I've Implemented one shared (Every instance) and one unique(One for every FD)
data.

Christian