summaryrefslogtreecommitdiffstats
path: root/include/linux/acpi.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2023-05-03 10:13:41 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2023-05-03 10:37:22 -0700
commit798dec3304f69b97cdf78f485473fb5653fc22d1 (patch)
tree28e46b4fe13db85eb857e510f945275415c12109 /include/linux/acpi.h
parent1dbc0a9515fdf1f0b9d6c9b1954a347c94e5f5f9 (diff)
downloadlinux-x86-uaccess-cleanup.tar.gz
linux-x86-uaccess-cleanup.tar.bz2
linux-x86-uaccess-cleanup.zip
x86-64: mm: clarify the 'positive addresses' user address rulesx86-uaccess-cleanup
Dave Hansen found the "(long) addr >= 0" code in the x86-64 access_ok checks somewhat confusing, and suggested using a helper to clarify what the code is doing. So this does exactly that: clarifying what the sign bit check is all about, by adding a helper macro that makes it clear what it is testing. This also adds some explicit comments talking about how even with LAM enabled, any addresses with the sign bit will still GP-fault in the non-canonical region just above the sign bit. This is all what allows us to do the user address checks with just the sign bit, and furthermore be a bit cavalier about accesses that might be done with an additional offset even past that point. (And yes, this talks about 'positive' even though zero is also a valid user address and so technically we should call them 'non-negative'. But I don't think using 'non-negative' ends up being more understandable). Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/acpi.h')
0 files changed, 0 insertions, 0 deletions