linux-kernel - Re: [PATCH] fuse: use kernel headers when __KERNEL_

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]

Date:	Tue, 16 Apr 2013 13:00:37 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"open list:FUSE: FILESYSTEM..." <fuse-devel@...ts.sourceforge.net>,
	Arve Hjønnevåg <arve@...roid.com>
Subject: Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set

On Tue, Apr 16, 2013 at 12:11 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Tue, Apr 16, 2013 at 8:29 PM, Colin Cross <ccross@...roid.com> wrote:
>> Dropping __linux__ causes a make headers_check warning, which the
>> kbuild test robot reported this morning:
>> usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
>> #include <linux/types.h>
>> Using my patch without modification does not cause that warning.
>>
>> linux/types.h defines the types that are used to communicate between
>> the kernel and userspace.  Redefining those in each header makes no
>> sense, and will probably cause redefined types warnings if you compile
>> a userspace file that includes fuse.h and another uapi header that
>> properly includes linux/types.h.
>
> <linux/types.h> is linux specific while the fuse API is cross
> platform.  So the userspace header obviously has to use some cross
> platform type definitions.  Making the type definitions depend on
> __linux__ is probably just as unreliable in userspace as it is in the
> kernel, so why complicate things with that?

I'm not sure what you mean by __linux__ being unreliable, it is set by
any toolchain that is compield with linux as its target.  It should be
very reliable in userspace, its only unreliable in the kernel because
the kernel doesn't rely on any specific os target in the toolchain, it
is self contained.

With your change, compiling a program that includes linux/fuse.h and
linux/icmp.h against the headers installed by make headers_installed
results in some strange preprocessor results.  The lines in
int-ll64.h, which is what normally defines the userspace types, are:
typedef __signed__ char __s8;
typedef unsigned char __u8;

typedef __signed__ short __s16;
typedef unsigned short __u16;

typedef __signed__ int __s32;
typedef unsigned int __u32;

After preprocessing with your fuse.h included before icmp.h (which
includes linux/types.h, which eventually includes
asm-generic/int-ll64.h):
typedef __signed__ char __s8;
typedef unsigned char __u8;

typedef __signed__ short __s16;
typedef unsigned short uint16_t;

typedef __signed__ int int32_t;
typedef unsigned int uint32_t;

The first three lines are the kernel headers providing typedefs for
the types that are not used in fuse.h, and therefore not covered by
the #define hacks there.  The last three lines are a problem: now you
have redefined the stdint types to match the kernel's types, better
hope they match the host's stdint definitions or you'll get redefined
type warnings.

Every other uapi header includes linux/types.h to get its type
definitions, and fuse.h should do the same when compiling for
userspace targeting linux or when compiling the kernel.
--
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/