lkml.org 
[lkml]   [2017]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC][CFT][PATCHSET v1] uaccess unification
On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
>
> I guess I can in next day or two - but mind you the inline version for ARC is kind
> of special vs. other arches. We have this "manual" constant propagation to elide
> the unrolled LD/ST for 1-15 byte stragglers, when @sz is constant.

I don't think that's special. We do that on x86 too, and I suspect ARC
copied it from there (or from somebody else who did it).

But at least on x86 is is limited entirely to the "__" versions, and
it's almost entirely pointless. We actually removed some of that kind
of code because it was *do* pointless, and it had just been copied
around into the "atomic" versions too.

See for example commit bd28b14591b9 ("x86: remove more uaccess_32.h
complexity"), which did that.

The basic "__" versions still do that constant-size thing, but they
really are questionable. Exactly because it's just the "__" versions -
the *regular* "copy_to/from_user()" is an unconditional function call,
because inlining it isn't just the access operations, it's the size
check, and on modern x86 it's also the "set AC to mark the user access
as safe".

.. and many distros enable some of the might_sleep() debugging code
etc. With any of that, inlining is simply a *bad* choice.

Linus

\
 
 \ /
  Last update: 2017-03-30 02:31    [W:1.109 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site