Arnd Bergmann <arnd@xxxxxxxx> writes: > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote: >> Here are the build results from automated periodic testing. >> >> The tree being built was stable-rc, found at: >> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/ >> >> Topmost commit: >> >> f821e08 Linux 4.4.31-rc1 >> >> Build logs (stderr only) can be found at the following link (experimental): >> >> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/ > > These seem to be largely caused by building with gcc-6. It's probably > a good idea to keep supporting that configuration though and > backport the fixes. Here are the upstream commit IDs I've found. > >> ------------------------------------------------------------------------------- >> >> Failed defconfigs: >> powerpc.pasemi_defconfig >> >> ------------------------------------------------------------------------------- >> > >> 1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare] > > I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of > devpts an independent filesystem."), which unfortunately is not a > candidate for stable Well eedf265aa003 ("devpts: Make each mount of devpts an independent filesystem.") does contain a somewhat serious bug fix, and it was tested to ensure it works everywhere so that might possibly be a canidate for stable. Certainly that is a change I would aim at vendor trees that care about containers. >> 1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare] > > Apparently also fixed as a side-effect of a larger patch: > > 9847371a84b0 ("netfilter: Allow xt_owner in any user namespace") > > This one might be appropriate for a stable backport, Eric Biederman > would know for sure. Well it is a feature patch. This sounds like an error message that is only generated when user namespace support is disabled. And we are making it go away by making the code more expensive. I am not a great fan of that warning being on by default, as it seems to encourage more expensive code to be generated by macros. Has that warning caught any real bugs yet? Eric -- 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