On Tue, Dec 24, 2013 at 12:46 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> Looks cool - it looks rather similar to the try/catch model Richard
> Henderson came up with many eons ago when we implemented the original
> exception mechanism for Linux, which IIRC we decided wasn't safe due
> to lack of compiler support.
>
> Now we have compiler support ... written by Richard Henderson ;-)
Interestingly, looking at the cp_new_stat() profiles, the games we
play to get efficient range checking seem to actually hurt us. Maybe
it's the "sbb" that is just expensive, or maybe it's turning a (very
predictable) conditional branch into a data dependency chain instead.
Or maybe it's just random noise in my profiles that happened to make
those sbb's look bad.
What do people think about this access_ok() simplification that gets
rid of inline asm, and instead optimizes the (reasonably common) case
of a constant size. The complex case that requires overflow checking
*might* get a bit slower (it's not clear: it really wasn't generating
wonderful code), but the simple case of a known constant size actually
gets simpler.
Random aside: this simplification made the special spurious
access_ok() check in kernel/futex.c (the NULL user pointer check in
futex_init()) just go away entirely, because the compiler could now
see that it can never trigger for a NULL pointer.. Not a performance
issue, but it was kind of funny to notice how getting rid of the
inline asm actually made the compiler able to notice that.
Linus
Attachment:
vfs-simplify-uaccess-range
Description: Binary data
