lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 18 Nov 2023 23:01:09 +0800 From: kernel test robot <lkp@...el.com> To: Kees Cook <keescook@...omium.org>, Anders Larsen <al@...rsen.net> Cc: oe-kbuild-all@...ts.linux.dev, Kees Cook <keescook@...omium.org>, Ronald Monthero <debug.penguin32@...il.com>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Hi Kees, kernel test robot noticed the following build errors: [auto build test ERROR on linus/master] [also build test ERROR on v6.7-rc1 next-20231117] [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/Kees-Cook/qnx4-Extract-dir-entry-filename-processing-into-helper/20231118-114223 base: linus/master patch link: https://lore.kernel.org/r/20231118033225.2181299-1-keescook%40chromium.org patch subject: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper config: i386-randconfig-011-20231118 (https://download.01.org/0day-ci/archive/20231118/202311182210.gREgIbSb-lkp@intel.com/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/20231118/202311182210.gREgIbSb-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@...el.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202311182210.gREgIbSb-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from fs/qnx4/dir.c:16:0: >> fs/qnx4/qnx4.h:86:51: error: expected ',' before ')' token offsetof(struct qnx4_link_info, dl_status)); ^ fs/qnx4/qnx4.h:88:56: error: expected ',' before ')' token offsetof(union qnx4_directory_entry, de_status)); ^ vim +86 fs/qnx4/qnx4.h 47 48 /* 49 * A qnx4 directory entry is an inode entry or link info 50 * depending on the status field in the last byte. The 51 * first byte is where the name start either way, and a 52 * zero means it's empty. 53 * 54 * Also, due to a bug in gcc, we don't want to use the 55 * real (differently sized) name arrays in the inode and 56 * link entries, but always the 'de_name[]' one in the 57 * fake struct entry. 58 * 59 * See 60 * 61 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6 62 * 63 * for details, but basically gcc will take the size of the 64 * 'name' array from one of the used union entries randomly. 65 * 66 * This use of 'de_name[]' (48 bytes) avoids the false positive 67 * warnings that would happen if gcc decides to use 'inode.di_name' 68 * (16 bytes) even when the pointer and size were to come from 69 * 'link.dl_name' (48 bytes). 70 * 71 * In all cases the actual name pointer itself is the same, it's 72 * only the gcc internal 'what is the size of this field' logic 73 * that can get confused. 74 */ 75 union qnx4_directory_entry { 76 struct { 77 const char de_name[48]; 78 u8 de_pad[15]; 79 u8 de_status; 80 }; 81 struct qnx4_inode_entry inode; 82 struct qnx4_link_info link; 83 }; 84 /* Make sure the status byte is in the same place for all structs. */ 85 _Static_assert(offsetof(struct qnx4_inode_entry, di_status) == > 86 offsetof(struct qnx4_link_info, dl_status)); 87 _Static_assert(offsetof(struct qnx4_inode_entry, di_status) == 88 offsetof(union qnx4_directory_entry, de_status)); 89 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists