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

["Christian A. Ehrhardt" <lk@c--e.de>]

Hi,

this is getting off topic but....

On Tue, Apr 21, 2026 at 09:53:57PM +0900, Takashi Sakamoto wrote:
> > 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.)

As far as in-memory syscall arguments are concerned a full support
for CHERI will essentially require a new UABI and also a new variant
of compat support to run standard non-CHERI aware 64-bit binaries.
This is the main reason for the size of the patchset.

> 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?

The in-memory representation of the fat pointer is 128-bit on a 64-bit
system. The 129-th bit (called the "tag bit") is not directly accessible
but managed out-of-band by the memory controller or some similar entity.
It is set on valid pointers only and is implicitly cleared when memory
is accessed with non-pointer instructions.

Best regards,
Christian