From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5412228895977513479==" MIME-Version: 1.0 From: Josh Triplett To: kbuild-all@lists.01.org Subject: Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall Date: Tue, 12 Nov 2019 14:02:09 -0800 Message-ID: <20191112220209.GB31753@localhost> In-Reply-To: <20191105144414.bvyj33w7i2cyhrpw@yavin.dot.cyphar.com> List-Id: --===============5412228895977513479== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Nov 06, 2019 at 01:44:14AM +1100, Aleksa Sarai wrote: > On 2019-11-05, kbuild test robot wrote: > > = > > FYI, we noticed a +573 bytes kernel size regression due to commit: > > = > > commit: 00f2dfd8c2a40f6dd7a74eae598a174484d848c4 (open: introduce opena= t2(2) syscall) > > = > > = > > Details as below (size data is obtained by `nm --size-sort vmlinux`): > > = > > 97a4cce0: namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resoluti= on > > 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". --===============5412228895977513479==--