On Mon, Dec 18, 2023 at 4:01 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > On Sat, Dec 16, 2023 at 12:53:43PM +0800, kernel test robot wrote: > > Hi Sebastian, > > > > kernel test robot noticed the following build errors: > > > > [auto build test ERROR on net-next/main] > > > > url: https://github.com/intel-lab-lkp/linux/commits/Sebastian-Andrzej-Siewior/locking-local_lock-Introduce-guard-definition-for-local_lock/20231216-011911 > > base: net-next/main > > patch link: https://lore.kernel.org/r/20231215171020.687342-21-bigeasy%40linutronix.de > > patch subject: [PATCH net-next 20/24] net: intel: Use nested-BH locking for XDP redirect. > > config: arm-defconfig (https://download.01.org/0day-ci/archive/20231216/202312161212.D5tju5i6-lkp@xxxxxxxxx/config) > > compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1) > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231216/202312161212.D5tju5i6-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/202312161212.D5tju5i6-lkp@xxxxxxxxx/ > > > > All errors (new ones prefixed by >>): > > > > >> drivers/net/ethernet/intel/igb/igb_main.c:8620:3: error: cannot jump from this goto statement to its label > > goto xdp_out; > > ^ ^ The problematic goto should be replaced with an early return. (and perhaps a comment that you can't jump over __cleanup variable initialization). Otherwise the compiler cannot put the cleanup in the destination basic block; it would have to split the edges and have all the happy paths go to a synthesized basic block that runs the cleanup, then jumps to the original destination. > > drivers/net/ethernet/intel/igb/igb_main.c:8624:2: note: jump bypasses initialization of variable with __attribute__((cleanup)) > > guard(local_lock_nested_bh)(&bpf_run_lock.redirect_lock); > > ^ > > include/linux/cleanup.h:142:15: note: expanded from macro 'guard' > > CLASS(_name, __UNIQUE_ID(guard)) > > ^ > > include/linux/compiler.h:180:29: note: expanded from macro '__UNIQUE_ID' > > #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) > > ^ > > include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE' > > #define __PASTE(a,b) ___PASTE(a,b) > > ^ > > include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE' > > #define ___PASTE(a,b) a##b > > ^ > > <scratch space>:52:1: note: expanded from here > > __UNIQUE_ID_guard753 > > ^ > > 1 error generated. > > I initially thought that this may have been > https://github.com/ClangBuiltLinux/linux/issues/1886 but asm goto is not > involved here. > > This error occurs because jumping over the initialization of a variable > declared with __attribute__((__cleanup__(...))) does not prevent the > clean up function from running as one may expect it to, but could > instead result in the clean up function getting run on uninitialized > memory. A contrived example (see the bottom of the "Output" tabs for the > execution output): > > https://godbolt.org/z/9bvGboxvc > > While there is a warning from GCC in that example, I don't see one in > the kernel's case. I see there is an open GCC issue around this problem: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951 > > While it is possible that there may not actually be a problem with how > the kernel uses __attribute__((__cleanup__(...))) and gotos, I think > clang's behavior is reasonable given the potential footguns that this > construct has. > > Cheers, > Nathan > -- Thanks, ~Nick Desaulniers
