[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <665ea57e360a421c958fffa08da77920@AcuMS.aculab.com>
Date: Thu, 24 Sep 2020 14:20:09 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'YiFei Zhu' <zhuyifei1999@...il.com>
CC: "containers@...ts.linux-foundation.org"
<containers@...ts.linux-foundation.org>,
YiFei Zhu <yifeifz2@...inois.edu>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Aleksa Sarai <cyphar@...har.com>,
"Andrea Arcangeli" <aarcange@...hat.com>,
Andy Lutomirski <luto@...capital.net>,
Dimitrios Skarlatos <dskarlat@...cmu.edu>,
Giuseppe Scrivano <gscrivan@...hat.com>,
Hubertus Franke <frankeh@...ibm.com>,
Jack Chen <jianyan2@...inois.edu>,
Jann Horn <jannh@...gle.com>,
Josep Torrellas <torrella@...inois.edu>,
Kees Cook <keescook@...omium.org>,
Tianyin Xu <tyxu@...inois.edu>,
Tobin Feldman-Fitzthum <tobin@....com>,
Tycho Andersen <tycho@...ho.pizza>,
Valentin Rothberg <vrothber@...hat.com>,
Will Drewry <wad@...omium.org>
Subject: RE: [PATCH v2 seccomp 2/6] asm/syscall.h: Add syscall_arches[] array
From: YiFei Zhu
> Sent: 24 September 2020 15:17
>
> On Thu, Sep 24, 2020 at 8:47 AM David Laight <David.Laight@...lab.com> wrote:
> > I doubt the compiler will do what you want.
> > Looking at it, in most cases there are one or two entries.
> > I think only MIPS has three.
>
> It does ;) GCC 10.2.0:
>
> $ objdump -d kernel/seccomp.o | less
> [...]
> 0000000000001520 <__seccomp_filter>:
> [...]
> 1587: 41 8b 54 24 04 mov 0x4(%r12),%edx
> 158c: b9 08 01 00 00 mov $0x108,%ecx
> 1591: 81 fa 3e 00 00 c0 cmp $0xc000003e,%edx
> 1597: 75 2e jne 15c7 <__seccomp_filter+0xa7>
> [...]
> 15c7: 81 fa 03 00 00 40 cmp $0x40000003,%edx
> 15cd: b9 40 01 00 00 mov $0x140,%ecx
> 15d2: 74 c5 je 1599 <__seccomp_filter+0x79>
> 15d4: 0f 0b ud2
> [...]
> 0000000000001cb0 <seccomp_cache_prepare>:
> [...]
> 1cc4: 41 b9 3e 00 00 c0 mov $0xc000003e,%r9d
> [...]
> 1dba: 41 b9 03 00 00 40 mov $0x40000003,%r9d
> [...]
> 0000000000002e30 <proc_pid_seccomp_cache>:
> [...]
> 2e72: ba 3e 00 00 c0 mov $0xc000003e,%edx
> [...]
> 2eb5: ba 03 00 00 40 mov $0x40000003,%edx
>
> Granted, I have CC_OPTIMIZE_FOR_PERFORMANCE rather than
> CC_OPTIMIZE_FOR_SIZE, but this patch itself is trying to sacrifice
> some of the memory for speed.
Don't both CC_OPTIMIZE_FOR_PERFORMANCE (-??) and CC_OPTIMIZE_FOR_SIZE (-s)
generate terrible code?
Try with a slghtly older gcc.
I think that entire optimisation (discarding const arrays)
is very recent.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists