FYI, we noticed a +573 bytes kernel size regression due to commit: commit: 00f2dfd8c2a40f6dd7a74eae598a174484d848c4 (open: introduce openat2(2) syscall) Details as below (size data is obtained by `nm --size-sort vmlinux`): 97a4cce0: namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution 00f2dfd8: open: introduce openat2(2) syscall +-----------------------+----------+----------+-------+ | symbol | 97a4cce0 | 00f2dfd8 | delta | +-----------------------+----------+----------+-------+ | bzImage | 439168 | 439424 | 256 | | nm.t.build_open_flags | 214 | 349 | 135 | | nm.T.__se_sys_openat2 | 0 | 122 | 122 | | nm.T.sys_openat2 | 0 | 122 | 122 | | nm.t.do_sys_openat2 | 0 | 116 | 116 | | nm.t.build_open_how | 0 | 78 | 78 | | nm.T.file_open_name | 41 | 73 | 32 | | nm.T.file_open_root | 52 | 84 | 32 | | nm.D.sys_call_table | 1744 | 1752 | 8 | | nm.T.__se_sys_openat | 26 | 23 | -3 | | nm.T.sys_openat | 26 | 23 | -3 | | nm.T.__se_sys_open | 27 | 24 | -3 | | nm.T.sys_open | 27 | 24 | -3 | | nm.T.do_sys_open | 121 | 61 | -60 | +-----------------------+----------+----------+-------+

On Wed, Nov 06, 2019 at 01:44:14AM +1100, Aleksa Sarai wrote: > On 2019-11-05, kbuild test robot <lkp(a)intel.com&gt; wrote: > > > > FYI, we noticed a +573 bytes kernel size regression due to commit: > > > > commit: 00f2dfd8c2a40f6dd7a74eae598a174484d848c4 (open: introduce openat2(2) syscall) > > > > > > Details as below (size data is obtained by `nm --size-sort vmlinux`): > > > > 97a4cce0: namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution > > 00f2dfd8: open: introduce openat2(2) syscall > > > > +-----------------------+----------+----------+-------+ > > | symbol | 97a4cce0 | 00f2dfd8 | delta | > > +-----------------------+----------+----------+-------+ > > | bzImage | 439168 | 439424 | 256 | > > | nm.t.build_open_flags | 214 | 349 | 135 | > > | nm.T.__se_sys_openat2 | 0 | 122 | 122 | > > | nm.T.sys_openat2 | 0 | 122 | 122 | > > | nm.t.do_sys_openat2 | 0 | 116 | 116 | > > | nm.t.build_open_how | 0 | 78 | 78 | > > | nm.T.file_open_name | 41 | 73 | 32 | > > | nm.T.file_open_root | 52 | 84 | 32 | > > | nm.D.sys_call_table | 1744 | 1752 | 8 | > > | nm.T.__se_sys_openat | 26 | 23 | -3 | > > | nm.T.sys_openat | 26 | 23 | -3 | > > | nm.T.__se_sys_open | 27 | 24 | -3 | > > | nm.T.sys_open | 27 | 24 | -3 | > > | nm.T.do_sys_open | 121 | 61 | -60 | > > +-----------------------+----------+----------+-------+ > > I'm not sure I understand what is meant by "regression" in this context. > Surely new code will always result in a code size increase. Or is it > that the largest symbols are increasing in size? Is there something I > should do, or is it reasonable that the size has increased (given my > changes in build_open_flags)? It would be nice if (for instance) it was possible to compile out the old openat and *only* support openat2, or otherwise compile out unused syscalls. In general, we're watching for new code that can't be built out of the kernel even in "allnoconfig"/"tinyconfig".