On Fri, Feb 18, 2022 at 1:30 AM David Laight [off-list ref] wrote:

From: Andy Lutomirski

quoted

Sent: 17 February 2022 19:15

...

quoted

This isn't actually optimal.  On x86, TASK_SIZE_MAX is a bizarre
constant that has a very specific value to work around a bug^Wdesign
error^Wfeature of Intel CPUs.  TASK_SIZE_MAX is the maximum address at
which userspace is permitted to allocate memory, but there is a huge
gap between user and kernel addresses, and any value in the gap would
be adequate for the comparison.  If we wanted to optimize this, simply
checking the high bit (which x86 can do without any immediate
constants at all) would be sufficient and, for an access known to fit
in 32 bits, one could get even fancier and completely ignore the size
of the access.  (For accesses not known to fit in 32 bits, I suspect
some creativity could still come up with a construction that's
substantially faster than the one in your patch.)

So there's plenty of room for optimization here.

(This is not in any respect a NAK -- it's just an observation that
this could be even better.)

For 64bit arch that use the top bit to separate user/kernel
you can test '(addr | size) >> 62)'.
The compiler optimises out constant sizes.

This has all been mentioned a lot of times.
You do get different fault types.

OTOH an explicit check for constant size (less than something big)
can use the cheaper test of the sign bit.
Big constant sizes could be compile time errors.

The different fault type issue may well be a real problem.  Right now
the core x86 fault code reserves the right to grouch if we get #GP
instead of #PF.  We could change that.