* [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
@ 2019-11-05 14:15 kbuild test robot
2019-11-05 14:44 ` Aleksa Sarai
0 siblings, 1 reply; 5+ messages in thread
From: kbuild test robot @ 2019-11-05 14:15 UTC (permalink / raw)
To: kbuild-all
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
2019-11-05 14:15 [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall kbuild test robot
@ 2019-11-05 14:44 ` Aleksa Sarai
2019-11-12 22:02 ` Josh Triplett
0 siblings, 1 reply; 5+ messages in thread
From: Aleksa Sarai @ 2019-11-05 14:44 UTC (permalink / raw)
To: kbuild-all
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
2019-11-05 14:44 ` Aleksa Sarai
@ 2019-11-12 22:02 ` Josh Triplett
2019-12-06 2:33 ` Aleksa Sarai
0 siblings, 1 reply; 5+ messages in thread
From: Josh Triplett @ 2019-11-12 22:02 UTC (permalink / raw)
To: kbuild-all
[-- 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".
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
2019-11-12 22:02 ` Josh Triplett
@ 2019-12-06 2:33 ` Aleksa Sarai
2019-12-25 10:03 ` Josh Triplett
0 siblings, 1 reply; 5+ messages in thread
From: Aleksa Sarai @ 2019-12-06 2:33 UTC (permalink / raw)
To: kbuild-all
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
2019-12-06 2:33 ` Aleksa Sarai
@ 2019-12-25 10:03 ` Josh Triplett
0 siblings, 0 replies; 5+ messages in thread
From: Josh Triplett @ 2019-12-25 10:03 UTC (permalink / raw)
To: kbuild-all
[-- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-12-25 10:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-05 14:15 [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall kbuild test robot
2019-11-05 14:44 ` Aleksa Sarai
2019-11-12 22:02 ` Josh Triplett
2019-12-06 2:33 ` Aleksa Sarai
2019-12-25 10:03 ` Josh Triplett
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.