Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct

["Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 4300 bytes --]

Hello Takashi,

On Tue, Apr 21, 2026 at 09:53:57PM +0900, Takashi Sakamoto wrote:
> On Mon, Apr 20, 2026 at 07:39:32PM +0200, Christian A. Ehrhardt wrote:
> > On Mon, Apr 20, 2026 at 06:08:16PM +0900, Takashi Sakamoto wrote:
> > > Just out of curiosity, what does the CHERI extension adopted to RISC-V
> > > architecture require in terms of kernel programming? Is taking extra
> > > care when storing pointer values in long-type variables sufficient in
> > > driver code?
> > 
> > That is a significant part but there is more to it (entry code,
> > register size changes, the UABI should better be CHERI aware, ...).
> > 
> > But the issue that a pointer does not fit into an unsigned long
> > is an issue that pops up all over the kernel while most other
> > changes are more localized.
> > 
> > There is a working linux kernel in the CHERI alliance github here:
> >    https://github.com/CHERI-Alliance/linux/tree/codasip-cheri-riscv-6.18
> > That definitely needs more cleanup but it does work.
> > Previous work from ARM for the morello project (another CHERI
> > enabled platform) is available here:
> >    https://git.morello-project.org/morello/kernel/linux
> > These should give a rough idea of what is required.
> > 
> > Fixing unsigned long vs. uintptr_t issues helps a lot with this
> > because it reduces the diff. But it is also a general cleanup.
> 
> Thsnks for the references. It looks like there is not much to consider
> outside of mm subsystem. But I have some concerns if supporting
> ARM/RISC-V adoptation of CHERI extension in Linux FireWire subsystem.
> 
> Any structures in UAPI header of this subsystem are defined with
> an assumption that the size of pointer in the existing System V
> architectures is up to 64 bits at most. We can see many usage of
> '__u64' type member for pointers (e.g. 'rom' in fw_cdev_get_info
> structure). I imagine to need defining specific structures for this kind
> of 'fat' pointer. (The same assumption lays on compat ioctl.)

The Standard C answer to that is: The assumption that you can fit a
pointer in an unsigned long or u64 is not generally justified. This is
"only" given for all current Linux archtectures. And if you want an
integer type to store a pointer, use uintptr_t. (And my position is that
you better try to keep pointers in pointer variables, though there are
some situations where you don't come around the conversion to an integer
type. That's why I introduced the union instead of converting to
uintptr_t.)

> As another concern is that the padding in structure. As long as I know,
> any 64 bit architecture for System V ABI has 8 bit alignment rule, and
> any structure in UAPI header of this subsystem are carefully defined not
> to have different sizes between x86/32bit/64bit architectures, except for
> 'fw_cdev_event_response' structure (see 'drivers/firewire/uapi-test.c').
> As a quick glance, the size of pointer in ARM CHERI extension seems to be
> 129 bit. In this case, what size of alignment rule is applied? Is there
> 7 bit padding after pointer member in any aggregates?

On CHERI pointers must be 128 bit aligned. Unaligned pointers yield a
hardware exception on usage. But that the ABI for CHERI is different
due to different sizes of some types is only a concern for CHERI-enabled
platforms. On non-CHERI everything stays as it is as
sizeof(union { kernel_ulong_t; void *; }) == sizeof(kernel_ulong_t) ==
sizeof(void *) == sizeof(uintptr_t). And there is no state that needs to
be maintained on CHERI-enabled systems, as they are new.

A pointer is 128 bit plus a validity flag that is stored elsewhere
(which is necessary to not give processes a means to craft valid
pointers). So for the purpose of a user space program and also for most
parts of the kernel, a pointer can be considered to be 128 bit as the
additional bit is (mostly) managed by hardware.

I see the challenge to introduce CHERI in mainline Linux somewhat
similar to the time when the first 64bit architectures came up and the
kernel still contained various assumptions about pointers and longs
being 32bit. Assuming CHERI keeps traction things will be addressed
over time and for the purpose of this series shouldn't be a concern now.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]