[lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]


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   |
+-----------------------+----------+----------+-------+



Thanks,
Kbuild test robot

Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On 2019-11-05, kbuild test robot <lkp@intel.com> 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)?

Thanks.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[Josh Triplett]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

On Wed, Nov 06, 2019 at 01:44:14AM +1100, Aleksa Sarai wrote:
> On 2019-11-05, kbuild test robot <lkp@intel.com> 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".

Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]

On 2019-11-12, Josh Triplett <josh@joshtriplett.org> wrote:
> On Wed, Nov 06, 2019 at 01:44:14AM +1100, Aleksa Sarai wrote:
> > On 2019-11-05, kbuild test robot <lkp@intel.com> 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".

Based on discussions with the glibc folks, it appears it's not longer
their policy to emulate syscalls in userspace due to all of the
headaches associated with it.

So while you could (with some work) emulate openat(2) with openat2(2), I
don't think there's a clear path to making openat(2) optional -- much
like open(2) didn't become optional after openat(2).

But I will be mindful of that policy in the future.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall

[Josh Triplett]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Fri, Dec 06, 2019 at 01:33:46PM +1100, Aleksa Sarai wrote:
> On 2019-11-12, Josh Triplett <josh@joshtriplett.org> wrote:
> > 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".
> 
> Based on discussions with the glibc folks, it appears it's not longer
> their policy to emulate syscalls in userspace due to all of the
> headaches associated with it.
> 
> So while you could (with some work) emulate openat(2) with openat2(2), I
> don't think there's a clear path to making openat(2) optional -- much
> like open(2) didn't become optional after openat(2).

Not all embedded systems run glibc. If your userspace consists of a
single application or a small set of applications, or you compile
everything against a known set of libraryies that make all the syscalls,
you can know that either everything uses the new syscall or everything
uses the old syscall, and compile out the one you don't use.