linux-kernel - Re: [PATCH v4 71/79] include/uapi/linux/fuse.h: use linux/types.h also in userspace

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 15 Oct 2015 21:25:30 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Mikko Rapeli <mikko.rapeli@....fi>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH v4 71/79] include/uapi/linux/fuse.h: use linux/types.h
 also in userspace

On Thu, Oct 15, 2015 at 8:59 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thursday 15 October 2015 20:32:45 Miklos Szeredi wrote:
>> > In my other patches I got review comments that kernel headers should not
>> > use <stdint.h> and also Documentation/CodingStyle section 5 says:
>> >
>> >  (e) Types safe for use in userspace.
>> >
>> >      In certain structures which are visible to userspace, we cannot
>> >      require C99 types and cannot use the 'u32' form above. Thus, we
>> >      use __u32 and similar types in all structures which are shared
>> >      with userspace.
>>
>> Ok, if you cannot require C99, then the __uXX types are the way to go.
>> But for the fuse API we *can* use C99 types, nothing preventing us
>> from doing it.
>
> What the sentence above means is that you should not rely on the
> user including <stdint.h> before including a kernel header, and
> that kernel headers are not allowed to include <stdint.h> themselves,
> because that would break any pre-C99 user space that defines types
> with the same names in their own headers and that relies on that
> header not to be included implicitly.
>
> It's possible that it has never been a problem for the fuse headers,
> but it has been a problem for other headers in the past and what
> Mikko is trying to achieve is to ensure that none of the kernel
> headers do this so we can make it an error in 'make headers_install'.

"in some cases including <stdint.h> might be a problem" is not a very
strong argument in favour of making it an error.  And since it would
be a step backwards for the fuse header I object to making it an
error.

If this is really such a big issue, then why not make it a warning
(and add a mechanism to silence that warning)?

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/