[PATCH 0/2] kbuild: Fix corner caches with .cache.mk

[PATCH 0/2] kbuild: Fix corner caches with .cache.mk

[Douglas Anderson]

This two-patches fixes two corner cases with .cache.mk that have been
reported recently.  Neither problem was catastrophic, but certainly
several people ran into the problem solved by the first patch (can't
build after gcc upgrade) and wasted time debugging, so it's really a
good idea to fix.

For both patches, please make sure to give them an extra thorough
review.  I _think_ I understand enough about $(MAKECMDGOALS), but I'd
never explored that feature of make before writing these patches so
the patches certainly need someone more experienced to give them a
careful look.

I've only got one more day of work before I'm on Christmas vacation
for 2 weeks, so if there are problems with these patches please give
me a bit of time to fix.  ...or, if someone is in a hurry, I wouldn't
object to someone else hijacking them and posting fixes.


Douglas Anderson (2):
  kbuild: Require a 'make clean' if we detect gcc changed underneath us
  kbuild: Don't mess with the .cache.mk when installing

 scripts/Kbuild.include | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

-- 
2.15.1.620.gb9897f4670-goog

[PATCH 1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us

[Douglas Anderson]

Several people reported that the commit 3298b690b21c ("kbuild: Add a
cache for generated variables") caused them problems when they updated
gcc versions.  Specifically the reports all looked something similar
to this:

> 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>

Masahiro Yamada determined that the problem was with:

  NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
  -print-file-name=include)

Specifically that the stale result of -print-file-name is stored in
the cache file.  It was determined that a "make clean" fixed the
problems in all cases.

In this particular case we could certainly try to clean just the cache
when we detect a gcc update, but it seems like overall it's a bad idea
to do an incremental build when gcc changes.  We should warn the user
and tell them that they need a 'make clean'.

Fixes: 3298b690b21c ("kbuild: Add a cache for generated variables")
Reported-by: Yang Shi <yang.s@alibaba-inc.com>
Reported-by: Dave Hansen <dave.hansen@intel.com>
Reported-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 scripts/Kbuild.include | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 065324a8046f..56dee20fb2b8 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -222,6 +222,10 @@ cc-version = $(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-version.
 cc-fullversion = $(call shell-cached,$(CONFIG_SHELL) \
 	$(srctree)/scripts/gcc-version.sh -p $(CC))
 
+# cc-fullversion-uncached
+cc-fullversion-uncached := $(shell $(CONFIG_SHELL) \
+	$(srctree)/scripts/gcc-version.sh -p $(CC))
+
 # cc-ifversion
 # Usage:  EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
 cc-ifversion = $(shell [ $(cc-version) $(1) $(2) ] && echo $(3) || echo $(4))
@@ -475,3 +479,14 @@ endif
 endef
 #
 ###############################################################################
+
+# Require a 'make clean' if the compiler changed; not only does the .cache.mk
+# need to be thrown out but we should also start with fresh object files.
+#
+# NOTE: it's important that we don't error out when the goal is actually to
+# try to make clean, distclean or mrproper.
+ifeq ($(filter %clean,$(MAKECMDGOALS))$(filter mrproper,$(MAKECMDGOALS)),)
+  ifneq ($(cc-fullversion-uncached),$(cc-fullversion))
+    $(error Detected new CC version ($(cc-fullversion-uncached) vs $(cc-fullversion)).  Please 'make clean')
+  endif
+endif
-- 
2.15.1.620.gb9897f4670-goog

[PATCH 2/2] kbuild: Don't mess with the .cache.mk when installing

[Douglas Anderson]

As pointed out by Masahiro Yamada people often run "sudo make install"
or "sudo make modules_install".  In theory, that could cause a cache
file (or the directory containing it) to be created by root.  After
doing this then subsequent invocations to make would yell with a whole
bunch of warnings like:

  /bin/sh: ./.cache.mk: Permission denied

These yells would be mostly harmless (we'd just go on running without
the cache), but they're ugly.

The above situation would be fairly unlikely because it should only
happen if someone does "sudo make install" before doing a normal
"make", which is an invalid thing to do.  If you did a normal "make"
before the "sudo make install" then all the cache files and
directories should have already been created by a normal user and,
even if the superuser needed to add to the existing files, we wouldn't
end up with a permission problem.

The above situation would also not have been catastrophic because
presumably if the user was able to run "sudo make install" then they
should also be able to run "sudo make clean" to clean things up.

However, even though the problem described is relatively minor, it
probably makes sense to add a heuristic to avoid creating cache files
when one of the make goals looks like an install.  This heuristic
doesn't add a ton of overhead and it might save someone time tracking
down strange "Permission denied" messages.  We'll consider this
heuristic good enough because the problem really shouldn't be that
serious.

Fixes: 3298b690b21c ("kbuild: Add a cache for generated variables")
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 scripts/Kbuild.include | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 56dee20fb2b8..e18235cd9570 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -124,6 +124,12 @@ __sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst $(left_paren),_,$
 # previous invocation of make!) we'll return the value.  If not, we'll
 # compute it and store the result for future runs.
 #
+# NOTE: we won't ever add to the cache if one of the make goals looks like
+# it is installing.  Technically there's no reason we can't cache things
+# related to install but it's likely that 'make install' is called as root.
+# If we create the cache file as root we might have a hard time adding to it
+# (or deleting it in make clean).
+#
 # This is a bit of voodoo, but basic explanation is that if the variable
 # was undefined then we'll evaluate the shell command and store the result
 # into the variable.  We'll then store that value in the cache and finally
@@ -137,12 +143,14 @@ __sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst $(left_paren),_,$
 define __run-and-store
 ifeq ($(origin $(1)),undefined)
   $$(eval $(1) := $$(shell $$(2)))
+ifeq ($(filter %install,$(MAKECMDGOALS)),)
 ifeq ($(create-cache-dir),1)
   $$(shell mkdir -p $(dir $(make-cache)))
   $$(eval create-cache-dir :=)
 endif
   $$(shell echo '$(1) := $$($(1))' >> $(make-cache))
 endif
+endif
 endef
 __shell-cached = $(eval $(call __run-and-store,$(1)))$($(1))
 shell-cached = $(call __shell-cached,__cached_$(call __sanitize-opt,$(1)),$(1))
-- 
2.15.1.620.gb9897f4670-goog

Re: [PATCH 1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us

[Doug Anderson]

Hi,

On Fri, Dec 22, 2017 at 1:58 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Thu, Dec 21, 2017 at 05:53:02PM -0800, Douglas Anderson wrote:
>> Several people reported that the commit 3298b690b21c ("kbuild: Add a
>> cache for generated variables") caused them problems when they updated
>> gcc versions.  Specifically the reports all looked something similar
>> to this:
>>
>> > 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>
>>
>> Masahiro Yamada determined that the problem was with:
>>
>>   NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
>>   -print-file-name=include)
>>
>> Specifically that the stale result of -print-file-name is stored in
>> the cache file.  It was determined that a "make clean" fixed the
>> problems in all cases.
>>
>> In this particular case we could certainly try to clean just the cache
>> when we detect a gcc update, but it seems like overall it's a bad idea
>> to do an incremental build when gcc changes.  We should warn the user
>> and tell them that they need a 'make clean'.
>>
>> Fixes: 3298b690b21c ("kbuild: Add a cache for generated variables")
>> Reported-by: Yang Shi <yang.s@alibaba-inc.com>
>> Reported-by: Dave Hansen <dave.hansen@intel.com>
>> Reported-by: Mathieu Malaterre <malat@debian.org>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
> Unfortunately, it doesn't work as-is. Trying to build for mips with two
> different compilers, and trying to run "make clean" with the 2nd compiler
> version, results in:
>
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'.  Stop.
> Makefile:1297: recipe for target '_clean_.' failed
> make: *** [_clean_.] Error 2
> make: *** Waiting for unfinished jobs....
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'.  Stop.
> Makefile:1297: recipe for target '_clean_arch/mips' failed
> make: *** [_clean_arch/mips] Error 2
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'.  Stop.
> Makefile:1297: recipe for target '_clean_arch/mips/boot/dts' failed
> make: *** [_clean_arch/mips/boot/dts] Error 2
> make: *** wait: No child processes.  Stop.

Indeed.  I tried poking around myself today and I clearly saw this
too.  I believe I was just doing very simple test cases of "make help"
/ "make clean" yesterday and I thought that would be fine as a
testcase, but clearly not.  When I did a more normal make it was easy
to reproduce this.

Poking around it looks like MAKECMDGOALS is somehow blank sometimes as
part of a "make clean".  I'll post a v2 that prevents showing the
error in that case too.  I'll repeat the caveat that's in my cover
letter that I'm a little lost when it comes to MAKECMDGOALS and how
they get set in all cases, so hopefully this is the right fix.

Sorry for the noise.

I'm going to go ahead and post v2 today even though perhaps not
everyone is done looking at v1.  This is because I'll soon disappear
on vacation and I'd rather have a possible fix out there.  Hopefully
that's OK w/ everyone.

-Doug

Re: [PATCH 1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us

[Guenter Roeck]

On Thu, Dec 21, 2017 at 05:53:02PM -0800, Douglas Anderson wrote:
> Several people reported that the commit 3298b690b21c ("kbuild: Add a
> cache for generated variables") caused them problems when they updated
> gcc versions.  Specifically the reports all looked something similar
> to this:
> 
> > 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>
> 
> Masahiro Yamada determined that the problem was with:
> 
>   NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
>   -print-file-name=include)
> 
> Specifically that the stale result of -print-file-name is stored in
> the cache file.  It was determined that a "make clean" fixed the
> problems in all cases.
> 
> In this particular case we could certainly try to clean just the cache
> when we detect a gcc update, but it seems like overall it's a bad idea
> to do an incremental build when gcc changes.  We should warn the user
> and tell them that they need a 'make clean'.
> 
> Fixes: 3298b690b21c ("kbuild: Add a cache for generated variables")
> Reported-by: Yang Shi <yang.s@alibaba-inc.com>
> Reported-by: Dave Hansen <dave.hansen@intel.com>
> Reported-by: Mathieu Malaterre <malat@debian.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Unfortunately, it doesn't work as-is. Trying to build for mips with two
different compilers, and trying to run "make clean" with the 2nd compiler
version, results in:

scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
Please 'make clean'.  Stop.
Makefile:1297: recipe for target '_clean_.' failed
make: *** [_clean_.] Error 2
make: *** Waiting for unfinished jobs....
scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
Please 'make clean'.  Stop.
Makefile:1297: recipe for target '_clean_arch/mips' failed
make: *** [_clean_arch/mips] Error 2
scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
Please 'make clean'.  Stop.
Makefile:1297: recipe for target '_clean_arch/mips/boot/dts' failed
make: *** [_clean_arch/mips/boot/dts] Error 2
make: *** wait: No child processes.  Stop.

Guenter