lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <fbac8306-247f-10f3-4067-14c0610b17d6@gmail.com> Date: Fri, 6 Dec 2019 08:19:03 -0800 From: Eric Dumazet <eric.dumazet@...il.com> To: Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <eric.dumazet@...il.com>, David Laight <David.Laight@...LAB.COM>, network dev <netdev@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: recvfrom/recvmsg performance and CONFIG_HARDENED_USERCOPY On 12/6/19 8:09 AM, Paolo Abeni wrote: > Oh, nice! I though the compiler was smart enough to avoid the indirect > call with the current code, but it looks like that least gcc 9.2.1 is > not. > > Thanks for pointing that out! > > In this specific scenario I think the code you propose above is better > than INDIRECT_CALL. > > Would you submit the patch formally? Certainly, although I am not sure this will be enough to close the gap between recvmsg() and recvfrom() :) Also I was wondering if a likely() or unlikely() clause would make sense. This could prevent an over zealous compiler optimizer to put back the indirect call that we tried to avoid.
Powered by blists - more mailing lists