linux-kernel - Re: [PATCH v2] fuse: uapi: use UAPI types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <519e25f7-ee5a-4458-b2cf-df3c3eb3694f@bsbernd.com>
Date: Fri, 9 Jan 2026 12:36:33 +0100
From: Bernd Schubert <bernd@...ernd.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: David Laight <david.laight.linux@...il.com>, Arnd Bergmann
 <arnd@...db.de>, Miklos Szeredi <miklos@...redi.hu>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] fuse: uapi: use UAPI types



On 1/9/26 11:55, Thomas Weißschuh wrote:
> On Fri, Jan 09, 2026 at 11:45:33AM +0100, Bernd Schubert wrote:
>>
>>
>> On 1/9/26 11:38, David Laight wrote:
>>> On Fri, 9 Jan 2026 09:11:28 +0100
>>> Thomas Weißschuh <thomas.weissschuh@...utronix.de> wrote:
>>>
>>>> On Thu, Jan 08, 2026 at 11:12:29PM +0100, Bernd Schubert wrote:
>>>>>
>>>>>
>>>>> On 1/5/26 13:09, Arnd Bergmann wrote:  
>>>>>> On Mon, Jan 5, 2026, at 09:50, Bernd Schubert wrote:  
>>> ...
>>>>>> I don't think we'll find a solution that won't break somewhere,
>>>>>> and using the kernel-internal types at least makes it consistent
>>>>>> with the rest of the kernel headers.
>>>>>>
>>>>>> If we can rely on compiling with a modern compiler (any version of
>>>>>> clang, or gcc-4.5+), it predefines a __UINT64_TYPE__ macro that
>>>>>> could be used for custom typedef:
>>>>>>
>>>>>> #ifdef __UINT64_TYPE__
>>>>>> typedef __UINT64_TYPE__		fuse_u64;
>>>>>> typedef __INT64_TYPE__		fuse_s64;
>>>>>> typedef __UINT32_TYPE__		fuse_u32;
>>>>>> typedef __INT32_TYPE__		fuse_s32;
>>>>>> ...
>>>>>> #else
>>>>>> #include <stdint.h>
>>>>>> typedef uint64_t		fuse_u64;
>>>>>> typedef int64_t			fuse_s64;
>>>>>> typedef uint32_t		fuse_u32;
>>>>>> typedef int32_t			fuse_s32;
>>>>>> ...
>>>>>> #endif  
>>>>>
>>>>> I personally like this version.  
>>>>
>>>> Ack, I'll use this. Although I am not sure why uint64_t and __UINT64_TYPE__
>>>> should be guaranteed to be identical.
>>>
>>> Indeed, on 64bit the 64bit types could be 'long' or 'long long'.
>>> You've still got the problem of the correct printf format specifier.
>>> On 32bit the 32bit types could be 'int' or 'long'.
>>>
>>> stdint.h 'solves' the printf issue with the (horrid) PRIu64 defines.
>>> But I don't know how you find out what gcc's format checking uses.
>>> So you might have to cast all the values to underlying C types in
>>> order pass the printf format checks.
>>> At which point you might as well have:
>>> typedef unsigned int fuse_u32;
>>> typedef unsigned long long fuse_u64;
>>> _Static_assert(sizeof (fuse_u32) == 4 && sizeof (fuse_u64) == 8);
>>> And then use %x and %llx in the format strings.
> 
> These changes to format strings are what we are trying to avoid.
> 
>> The test PR from Thomas succeeds in compilation and build testing. Which
>> includes 32-bit cross compilation
>>
>> https://github.com/libfuse/libfuse/pull/1417
> 
> Unforunately there might still be issues on configurations not tested by the CI
> where the types between the compiler and libc won't match.
> But if it works sufficiently for you, I'm fine with it.

I don't have a problem to adopt libfuse - that is the simple part. The
harder part are other fuse implementations that use the same header. And
they will complain to Miklos if compilation fails.
Which is why it is important that we catch beforehand as many issues as
we can and then the commit message should explain very detailed the use
case. I.e. if something breaks for others, we can still point to you use
case that would be broken without these changes.

> 
> Also with the proposal from Arnd there were format strings warnings when
> building the kernel, so now I have this:
> 
> #if defined(__KERNEL__)
> #include <linux/types.h>
> typedef __u64		fuse_u64;
> ...
> 
> #elif defined(__UINT64_TYPE__)
> typedef __UINT64_TYPE__		fuse_u64;
> ...
> 
> #else
> #include <stdint.h>
> typedef uint64_t		fuse_u64;
> ...
> #endif  


I guess you can see why Miklos is resisting these changes without a good
use case :)


Thanks,
Bernd