On Thu, Jul 18, 2024 at 7:19 AM Kees Cook <[email protected]> wrote: > > On Wed, Jul 17, 2024 at 01:46:32PM +0900, Masahiro Yamada wrote: > > On Wed, Jul 17, 2024 at 2:51 AM kernel test robot <[email protected]> wrote: > > > > > > Hi Masahiro, > > > > > > kernel test robot noticed the following build errors: > > > > > > [auto build test ERROR on linus/master] > > > [also build test ERROR on v6.10 next-20240716] > > > [cannot apply to akpm-mm/mm-nonmm-unstable kees/for-next/hardening > > > kees/for-next/pstore kees/for-next/kspp] > > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > > And when submitting patch, we suggest to use '--base' as documented in > > > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > > > > > url: > > > https://github.com/intel-lab-lkp/linux/commits/Masahiro-Yamada/fortify-use-if_changed_dep-to-record-header-dependency-in-cmd-files/20240715-224820 > > > base: linus/master > > > patch link: > > > https://lore.kernel.org/r/20240715144529.101634-2-masahiroy%40kernel.org > > > patch subject: [PATCH 1/3] fortify: use if_changed_dep to record header > > > dependency in *.cmd files > > > config: i386-randconfig-004-20240716 > > > (https://download.01.org/0day-ci/archive/20240717/[email protected]/config) > > > compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 > > > reproduce (this is a W=1 build): > > > (https://download.01.org/0day-ci/archive/20240717/[email protected]/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new > > > version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot <[email protected]> > > > | Closes: > > > https://lore.kernel.org/oe-kbuild-all/[email protected]/ > > > > > > All errors (new ones prefixed by >>): > > > > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-memcpy.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.read_overflow2-memcmp.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.read_overflow-memchr.log.d: No such file or directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-strcpy-lit.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.read_overflow2-memmove.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-strncpy-src.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.read_overflow-memcmp.log.d: No such file or directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.read_overflow-memscan.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-strcpy.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-memmove.log.d: No such file or > > > >> directory > > > -- > > > >> fixdep: error opening file: > > > >> lib/test_fortify/.write_overflow-memset.log.d: No such file or > > > >> directory > > > .. > > > > > > > > This issue seems to occur with GCC <=7 > > > > > > $ echo 'void b(void) __attribute__((__error__(""))); void a(void) { > > b(); }' | gcc -Wp,-MMD,test.d -c -o /dev/null -x c - > > > > > > did not create *.d with GCC <= 7. > > > > I do not see the issue with GCC >= 8 or Clang. > > Any idea why this happens here and not for other sources in the tree?
Because the logic is opposite. For other locations, you need to write the correct code. When it is compiled successfully, *.d is generated as well. Under lib/test_fortify/, you intentionally incorrect code. GCC emits a compile error, and test_fortify.sh checks the error message. I believe *.d should be still generated unless a pre-processor error occurs. > > One quick solution is to skip the test for GCC <= 7. > > I'd be fine with that -- it is designed to catch regressions/misbehaviours > in newly release compilers so I don't mind dropping checks against older > versions. > > -- > Kees Cook -- Best Regards Masahiro Yamada
