Hi Serge, Thanks for confirming this looks sane... I also noticed that there's a problem if you're mixing up linux/ with sys/ with linux/ again, for instance: #include <linux/in6.h> // this includes libc-compat, and as _SYS_XATTR_H is not defined, it will define __UAPI_DEF_XATTR=1 #include <sys/xattr.h> // __USE_KERNEL_XATTR_DEFS is not defined (because linux/xattr.h was not sourced yet) so it will define XATTR_CREATE. #include <linux/xattr.h> // previous libc-compat defined __UAPI_DEF_XATTR=1, so it will try to redefine XATTR_CREATE. Not sure if this is a huge problem as I don't really expect to source the includes in this order... But you might want to take a look if you can find a good solution for this include order. Cheers, Filipe On Fri, Aug 15, 2014 at 12:11 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote: > Quoting akpm@xxxxxxxxxxxxxxxxxxxx (akpm@xxxxxxxxxxxxxxxxxxxx): >> >> The patch titled >> Subject: xattr: fix check for simultaneous glibc header inclusion >> has been added to the -mm tree. Its filename is >> xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch >> >> This patch should soon appear at >> http://ozlabs.org/~akpm/mmots/broken-out/xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch >> and later at >> http://ozlabs.org/~akpm/mmotm/broken-out/xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch >> >> Before you just go and hit "reply", please: >> a) Consider who else should be cc'ed >> b) Prefer to cc a suitable mailing list as well >> c) Ideally: find the original patch on the mailing list and do a >> reply-to-all to that, adding suitable additional cc's >> >> *** Remember to use Documentation/SubmitChecklist when testing your code *** >> >> The -mm tree is included into linux-next and is updated >> there every 3-4 working days >> >> ------------------------------------------------------ >> From: Filipe Brandenburger <filbranden@xxxxxxxxxx> >> Subject: xattr: fix check for simultaneous glibc header inclusion >> >> The guard was introduced in ea1a8217b06b41 ("xattr: guard against >> simultaneous glibc header inclusion") but it is using #ifdef to check for >> a define that is either set to 1 or 0. Fix it to use #if instead. >> >> * Without this patch: >> $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null >> include/uapi/linux/xattr.h:19:0: warning: "XATTR_CREATE" redefined [enabled by default] >> #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */ >> ^ >> /usr/include/x86_64-linux-gnu/sys/xattr.h:32:0: note: this is the location of the previous definition >> #define XATTR_CREATE XATTR_CREATE >> ^ >> >> * With this patch: >> $ { echo "#include <sys/xattr.h>"; echo "#include <linux/xattr.h>"; } | gcc -E -Iinclude/uapi - >/dev/null >> (no warnings) >> >> Signed-off-by: Filipe Brandenburger <filbranden@xxxxxxxxxx> >> Cc: Serge Hallyn <serge.hallyn@xxxxxxxxxx> > > Thanks, what you say certainly makes sense. Making the change locally > doesn't seem to suffice (and I've had another not-yet-resolved issue > with redefines coming from the xattr package itself), but this change > looks correct. > > Acked-by: Serge E. Hallyn <serge.hallyn@xxxxxxxxxx> > >> Cc: Allan McRae <allan@xxxxxxxxxxxxx> >> Cc: <stable@xxxxxxxxxxxxxxx> >> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> >> --- >> >> include/uapi/linux/xattr.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff -puN include/uapi/linux/xattr.h~xattr-fix-check-for-simultaneous-glibc-header-inclusion include/uapi/linux/xattr.h >> --- a/include/uapi/linux/xattr.h~xattr-fix-check-for-simultaneous-glibc-header-inclusion >> +++ a/include/uapi/linux/xattr.h >> @@ -13,7 +13,7 @@ >> #ifndef _UAPI_LINUX_XATTR_H >> #define _UAPI_LINUX_XATTR_H >> >> -#ifdef __UAPI_DEF_XATTR >> +#if __UAPI_DEF_XATTR >> #define __USE_KERNEL_XATTR_DEFS >> >> #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */ >> _ >> >> Patches currently in -mm which might be from filbranden@xxxxxxxxxx are >> >> xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch >> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html