linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Alice Ryhl" <aliceryhl@google.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <brauner@kernel.org>,
	"Jan Kara" <jack@suse.cz>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] rust: miscdevice: add base miscdevice abstraction
Date: Wed, 02 Oct 2024 12:48:12 +0000	[thread overview]
Message-ID: <af1bf81f-ae37-48b9-87c0-acf39cf7eca7@app.fastmail.com> (raw)
In-Reply-To: <20241001-b4-miscdevice-v2-2-330d760041fa@google.com>

On Tue, Oct 1, 2024, at 08:22, Alice Ryhl wrote:
> +#[cfg(CONFIG_COMPAT)]
> +unsafe extern "C" fn fops_compat_ioctl<T: MiscDevice>(
> +    file: *mut bindings::file,
> +    cmd: c_uint,
> +    arg: c_ulong,
> +) -> c_long {
> +    // SAFETY: The compat ioctl call of a file can access the private 
> data.
> +    let private = unsafe { (*file).private_data };
> +    // SAFETY: Ioctl calls can borrow the private data of the file.
> +    let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) 
> };
> +
> +    match T::compat_ioctl(device, cmd as u32, arg as usize) {
> +        Ok(ret) => ret as c_long,
> +        Err(err) => err.to_errno() as c_long,
> +    }
> +}

I think this works fine as a 1:1 mapping of the C API, so this
is certainly something we can do. On the other hand, it would be
nice to improve the interface in some way and make it better than
the C version.

The changes that I think would be straightforward and helpful are:

- combine native and compat handlers and pass a flag argument
  that the callback can check in case it has to do something
  special for compat mode

- pass the 'arg' value as both a __user pointer and a 'long'
  value to avoid having to cast. This specifically simplifies
  the compat version since that needs different types of
  64-bit extension for incoming 32-bit values.

On top of that, my ideal implementation would significantly
simplify writing safe ioctl handlers by using the information
encoded in the command word:

 - copy the __user data into a kernel buffer for _IOW()
   and back for _IOR() type commands, or both for _IOWR()
 - check that the argument size matches the size of the
   structure it gets assigned to

We have a couple of subsystems in the kernel that already
do something like this, but they all do it differently.
For newly written drivers in rust, we could try to do
this well from the start and only offer a single reliable
way to do it. For drivers implementing existing ioctl
commands, an additional complication is that there are
many command codes that encode incorrect size/direction
data, or none at all.

I don't know if there is a good way to do that last bit
in rust, and even if there is, we may well decide to not
do it at first in order to get something working.

      Arnd

  parent reply	other threads:[~2024-10-02 12:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-01  8:22 [PATCH v2 0/2] Miscdevices in Rust Alice Ryhl
2024-10-01  8:22 ` [PATCH v2 1/2] rust: types: add Opaque::try_ffi_init Alice Ryhl
2024-10-01  8:46   ` Benno Lossin
2024-10-25  4:10   ` Trevor Gross
2024-10-25  7:57     ` Alice Ryhl
2024-10-01  8:22 ` [PATCH v2 2/2] rust: miscdevice: add base miscdevice abstraction Alice Ryhl
2024-10-01  8:53   ` Dirk Behme
2024-10-01  9:13     ` Alice Ryhl
2024-10-01 11:28   ` Alice Ryhl
2024-10-02 12:48   ` Arnd Bergmann [this message]
2024-10-02 12:58     ` Alice Ryhl
2024-10-02 13:24       ` Arnd Bergmann
2024-10-02 13:31         ` Alice Ryhl
2024-10-02 13:57           ` Arnd Bergmann
2024-10-02 14:23             ` Alice Ryhl
2024-10-02 15:31               ` Arnd Bergmann
2024-10-02 13:24     ` Christian Brauner
2024-10-02 13:36       ` Alice Ryhl
2024-10-02 14:23         ` Christian Brauner
2024-10-02 15:45           ` Arnd Bergmann
2024-10-02 16:04             ` Greg Kroah-Hartman
2024-10-02 20:08               ` Arnd Bergmann
2024-10-03  8:19               ` Christian Brauner
2024-10-03  8:09             ` Christian Brauner
2024-10-02 13:31   ` Christian Brauner
2024-10-02 14:06   ` Christian Brauner
2024-10-02 14:24     ` Alice Ryhl
2024-10-03  8:33       ` Christian Brauner
2024-10-21 10:34   ` Miguel Ojeda
2024-10-22 13:15     ` Alice Ryhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af1bf81f-ae37-48b9-87c0-acf39cf7eca7@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=brauner@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).