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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 07 Dec 2018 21:46:37 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Paul Turner <pjt@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/4] indirect call wrappers: helpers to
 speed-up indirect calls of builtin

On Fri, 2018-12-07 at 21:46 +0100, Paolo Abeni wrote:
> > I wonder if we can declare the common case functions as 'weak' so that
> > the link failures don't happen when they're absent.
> 
> I experimented a previous version with alias. I avoided weak alias
> usage, because I [mis?]understood not all compilers have a complete
> support for them (e.g. clang).
> Also, with weak ref, a coding error that is now discovered at build
> time will result in worse performance at runtime, likely with some
> uncommon configuration, possibly not as easily detected. I'm unsure
> that would be better ?!?

I think everything supports weak linkage; we've been using it for
years.

> > Once we extend this past the network code, especially to file systems'
> > f_ops, I suspect we're going to want to use something like static keys
> > to patch the common cases at runtime — perhaps changing the f_ops
> > default according to what the root file system is, etc.
> 
> I'm sorry, I don't follow here. I think static keys can't be used for
> the reported network case: we have different list elements each
> contaning a different function pointer and we access/use
> different ptr on a per packet basis.

Yes, the alternatives would be used to change the "likely" case.

We still do the "if (fn == default_fn) default_fn(); else (*fn)();"
part; or even the variant with two (or more) common cases. 

It's just that the value of 'default_fn' can be changed at runtime
(with patching like alternatives/static keys, since of course it has to
be a direct call).



Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ