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
| ||
|
Date: Thu, 21 Dec 2017 18:18:59 -0800 From: Doug Anderson <dianders@...omium.org> To: Masahiro Yamada <yamada.masahiro@...ionext.com> Cc: Yang Shi <yang.s@...baba-inc.com>, Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>, Guenter Roeck <linux@...ck-us.net>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables" Hello, On Wed, Dec 20, 2017 at 8:01 PM, Masahiro Yamada <yamada.masahiro@...ionext.com> wrote: > Hi Doug > > 2017-12-21 2:07 GMT+09:00 Doug Anderson <dianders@...omium.org>: >> Hi, >> >> On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada >> <yamada.masahiro@...ionext.com> wrote: >>> 2017-12-19 2:17 GMT+09:00 Doug Anderson <dianders@...omium.org>: >>>> Hi, >>>> >>>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada >>>> <yamada.masahiro@...ionext.com> wrote: >>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <yamada.masahiro@...ionext.com>: >>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <yang.s@...baba-inc.com>: >>>>>>> Hi folks, >>>>>>> >>>>>>> I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. But, >>>>>>> I ran into the below compile error with 4.15-rc3 kernel: >>>>>>> >>>>>>> In file included from ./include/uapi/linux/uuid.h:21:0, >>>>>>> from ./include/linux/uuid.h:19, >>>>>>> from ./include/linux/mod_devicetable.h:12, >>>>>>> from scripts/mod/devicetable-offsets.c:2: >>>>>>> ./include/linux/string.h:8:20: fatal error: stdarg.h: No such file or >>>>>>> directory >>>>>>> #include <stdarg.h> >>>>>>> >>>>>>> I bisected to commit 3298b690b21cdbe6b2ae8076d9147027f396f2b1 ("kbuild: Add >>>>>>> a cache for generated variables"). Once I revert this commit, kernel build >>>>>>> is fine. >>>>>>> >>>>>>> gcc 4.8.5 is fine to build kernel with this commit. >>>>>>> >>>>>>> I'm not quite sure if this is a bug or my gcc install is skewed although it >>>>>>> can build kernel without that commit since that commit might exacerbate the >>>>>>> case. >>>>>>> >>>>>>> Any hint is appreciated >>>>>> >>>>>> >>>>>> Today, I was also hit with the same error >>>>>> when I was compiling linux-next. >>>>>> I am not so sure why this error happens, but >>>>>> "make clean" will probably fix the problem. >>>>>> >>>>>> You need to do "make clean" to blow .cache.mk >>>>>> when you upgrade your compiler. >>>>>> This is nasty, though... >>>>>> >>>>> >>>>> >>>>> I got it. >>>>> >>>>> The following line in the top-level Makefile. >>>>> >>>>> NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) >>>>> -print-file-name=include) >>>>> >>>>> >>>>> If the stale result of -print-file-name is stored in the cache file, >>>>> the compiler fails to find <stdarg.h> >>>> >>>> Nice catch! Do you have any idea how we can fix it? I suppose we >>>> could add a single (non-cached) call to CC somewhere in there to get >>>> CC's version and clobber the cache if the version changes. Is that >>>> the best approach here? >>>> >>>> In general I remember thinking about the gcc upgrade problem when I >>>> was first experimenting with the cache. At the time my assumption was >>>> that if someone updated their gcc then they really ought to be doing a >>>> clean anyway (I wasn't sure if the build system somehow enforced this, >>>> but I didn't think so). Doing an incremental build after a compiler >>>> upgrade just seems (to me) to be asking for asking for trouble, or in >>>> the very least seems like it's not what the user wanted (if you update >>>> your compiler you almost certainly want it to be used to build all of >>>> your code, don't you?) >>> >>> I agree. >>> When you upgrade your compiler, >>> you need to remove not only cache files, but also all object files. >>> So, "make clean" is the most reasonable way. >>> >>> >>>> Even if it's wise to do a clean after a compiler upgrade, it still >>>> seems pretty non-ideal that a user has to decipher an arcane error >>>> like this, so it seems like we should see what we can do to detect >>>> this case for the user and help them out. Perhaps rather than >>>> clobbering the cache we should actually suggest that the user run a >>>> "make clean"? >>>> >>> >>> Right. I think it's a good thing to do. >> >> Are you planning on doing this, or is this something you'd like me to >> attempt? I'm a bit busy in the last two days before I go on Christmas >> break, but I can try to squeeze something like this in since the root >> of the issue is a patch that I authored. Let me know. > > I am busy too these days. > Your contribution is very appreciated. OK, I've attempted this. For anyone that might stumble upon this thread, here are links: * https://patchwork.kernel.org/patch/10128647/ [1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us * https://patchwork.kernel.org/patch/10128645/ [2/2] kbuild: Don't mess with the .cache.mk when installing >> If this is something you'd like me to do, let me know if you think the >> right solution is to detect the problem and warn the user or if the >> right solution is to just blow away the cache. It would be up to you, >> but I'd tend to go the route of warning the user because: >> >> * The user should almost certainly do a "make clean" to really ensure >> no mismatch between object files. >> >> * I could imagine that trying to invoke "make clean" automatically >> might be complicated. > > I agree with both. > > > When compiler upgrade is detected, > we can terminate building > with a hint message to prompt users to run "make clean" > > >> >>> BTW, "sudo make install" or "sudo make modules_install" could >>> add some cache entries by super user privilege? >>> >>> (For example, run build targets with CROSS_COMPILE, >>> but run install targets without CROSS_COMPILE, >>> install targets will produce different cache entries.) >>> >>> >>> If so, "make clean" in normal user privilege >>> can not remove cache files... >> >> Hrm. That doesn't sound nice. I guess this could be solved by >> something like your "no-compiler-targets" patch, but IIUC that didn't >> include "install" or "module_install". I guess the other option would >> be to somehow detect "UID=0" specifically and not generate the cache? >> >> -Doug > > That would be a solution. > We can skip cache generation for some sort of targets. When I thought about this and tested, I realized that this is a pretty unlikely scenario to run into (and also it's somewhat obvious what is happening). ...but I've posted up a patch in any case so you can see what you think. ;) -Doug
Powered by blists - more mailing lists