Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-172-g9a2dae1853-fm-20230213.001-g9a2dae18
Mime-Version: 1.0
Message-Id: <0818df3a-76c9-4cb3-8016-4717f4d5bf18@app.fastmail.com>
In-Reply-To: <20230224-rust-ioctl-v1-1-5142d365a934@asahilina.net>
References: <20230224-rust-ioctl-v1-1-5142d365a934@asahilina.net>
Date:   Fri, 24 Feb 2023 09:43:27 +0100
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Asahi Lina" <lina@asahilina.net>,
        "Miguel Ojeda" <ojeda@kernel.org>,
        "Alex Gaynor" <alex.gaynor@gmail.com>,
        "Wedson Almeida Filho" <wedsonaf@gmail.com>,
        "Boqun Feng" <boqun.feng@gmail.com>, "Gary Guo" <gary@garyguo.net>,
        =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>
Cc:     linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
        asahi@lists.linux.dev, Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] rust: ioctl: Add ioctl number manipulation functions
Content-Type: text/plain
Precedence: bulk

On Fri, Feb 24, 2023, at 08:36, Asahi Lina wrote:
> Add simple 1:1 wrappers of the C ioctl number manipulation functions.
> Since these are macros we cannot bindgen them directly, and since they
> should be usable in const context we cannot use helper wrappers, so
> we'll have to reimplement them in Rust. Thankfully, the C headers do
> declare defines for the relevant bitfield positions, so we don't need
> to duplicate that.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>

I don't know much rust yet, but it looks like a correct abstraction
that handles all the corner cases of architectures with unusual
_IOC_*MASK combinations the same way as the C version.

There is one corner case I'm not sure about:

> +/// Build an ioctl number, analogous to the C macro of the same name.
> +const fn _IOC(dir: u32, ty: u32, nr: u32, size: usize) -> u32 {
> +    core::assert!(dir <= bindings::_IOC_DIRMASK);
> +    core::assert!(ty <= bindings::_IOC_TYPEMASK);
> +    core::assert!(nr <= bindings::_IOC_NRMASK);
> +    core::assert!(size <= (bindings::_IOC_SIZEMASK as usize));
> +
> +    (dir << bindings::_IOC_DIRSHIFT)
> +        | (ty << bindings::_IOC_TYPESHIFT)
> +        | (nr << bindings::_IOC_NRSHIFT)
> +        | ((size as u32) << bindings::_IOC_SIZESHIFT)
> +}

This has the assertions inside of _IOC() while the C version
has them in the outer _IOR()/_IOW() /_IOWR() helpers. This was
intentional since some users of _IOC() pass a variable
length in rather than sizeof(type), and this would cause
a link failure in C.

How is the _IOC_SIZEMASK assertion evaluated here? It's
probably ok if this is a compile-time assertion that prevents
the variable-length arguments, but it would be bad if this
could lead to a BUG() or panic() in case of a user-supplied
length that is out of range.

     Arnd