Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct
"Christian A. Ehrhardt" <[email protected]> Tue, 21 Apr 2026 18:20:53 +0200
| Newsgroups | gmane.linux.sound,gmane.linux.kernel.firewire.devel |
|---|---|
| Message-ID | <[email protected]> |
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