Re: [PATCH 1/3] fortify: use if_changed_dep to record header dependency in *.cmd files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 18, 2024 at 7:19 AM Kees Cook <kees@xxxxxxxxxx> 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 <lkp@xxxxxxxxx> 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/202407170104.dCe5MKsA-lkp@xxxxxxxxx/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/202407170104.dCe5MKsA-lkp@xxxxxxxxx/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 <lkp@xxxxxxxxx>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202407170104.dCe5MKsA-lkp@xxxxxxxxx/
> > >
> > > 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





[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux