[PATCH v4 2/4] arch/x86: Move internal setup_data structures into setup_data.h
Nathan Chancellor
nathan at kernel.org
Thu Jan 11 22:41:08 UTC 2024
On Thu, Jan 11, 2024 at 10:50:43AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 09.01.24 um 18:58 schrieb Nathan Chancellor:
> > On Tue, Jan 09, 2024 at 08:28:59AM +0800, kernel test robot wrote:
> > > Hi Thomas,
> > >
> > > kernel test robot noticed the following build warnings:
> > >
> > > [auto build test WARNING on tip/x86/core]
> > > [also build test WARNING on efi/next tip/master tip/auto-latest linus/master v6.7 next-20240108]
> > > [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/Thomas-Zimmermann/arch-x86-Move-UAPI-setup-structures-into-setup_data-h/20240108-180158
> > > base: tip/x86/core
> > > patch link: https://lore.kernel.org/r/20240108095903.8427-3-tzimmermann%40suse.de
> > > patch subject: [PATCH v4 2/4] arch/x86: Move internal setup_data structures into setup_data.h
> > > config: x86_64-rhel-8.3-bpf (https://download.01.org/0day-ci/archive/20240109/202401090800.UOBEKB3W-lkp@intel.com/config)
> > > compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401090800.UOBEKB3W-lkp@intel.com/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 at intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202401090800.UOBEKB3W-lkp@intel.com/
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > In file included from arch/x86/realmode/rm/wakemain.c:3:
> > > In file included from arch/x86/boot/boot.h:24:
> > > In file included from arch/x86/include/asm/setup.h:10:
> > > In file included from arch/x86/include/asm/page_types.h:7:
> > > In file included from include/linux/mem_encrypt.h:17:
> > > In file included from arch/x86/include/asm/mem_encrypt.h:18:
> > > In file included from arch/x86/include/uapi/asm/bootparam.h:5:
> > > > > arch/x86/include/asm/setup_data.h:10:20: warning: field 'data' with variable sized type 'struct setup_data' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> > > 10 | struct setup_data data;
> > > | ^
> > > 1 warning generated.
> >
> > I think this warning is expected. This structure is now included in the
> > realmode part of arch/x86, which has its own set of build flags,
> > including -Wall, which includes -Wgnu on clang. The kernel obviously
> > uses GNU extensions and states this clearly with '-std=gnu11', so
> > -Wno-gnu is unconditionally added to KBUILD_CFLAGS for clang. It seems
> > that same treatment is needed for REALMODE_CFLAGS, which also matches
> > arch/x86/boot/compressed/Makefile, see commit 6c3b56b19730 ("x86/boot:
> > Disable Clang warnings about GNU extensions"):
> >
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 1a068de12a56..24076db59783 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -53,6 +53,9 @@ REALMODE_CFLAGS += -fno-stack-protector
> > REALMODE_CFLAGS += -Wno-address-of-packed-member
> > REALMODE_CFLAGS += $(cc_stack_align4)
> > REALMODE_CFLAGS += $(CLANG_FLAGS)
> > +ifdef CONFIG_CC_IS_CLANG
> > +REALMODE_CFLAGS += -Wno-gnu
> > +endif
>
> Thanks. Shall I include this change in the patchset?
Yes, I think so to keep the build clean.
> Best regards
> Thomas
>
> > export REALMODE_CFLAGS
> > # BITS is used as extension for files which are available in a 32 bit
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
More information about the Linux-security-module-archive
mailing list