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