mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-13 22:25:03 +00:00
e5c460f46a
This was found using Dave Jone's trinity tool. When a user process which is 32-bit performs a load or a store, the cpu chops off the top 32-bits of the effective address before translating it. This is because we run 32-bit tasks with the PSTATE_AM (address masking) bit set. We can't run the kernel with that bit set, so when the kernel accesses userspace no address masking occurs. Since a 32-bit process will have no mappings in that region we will properly fault, so we don't try to handle this using access_ok(), which can safely just be a NOP on sparc64. Real faults from 32-bit processes should never generate such addresses so a bug check was added long ago, and it barks in the logs if this happens. But it also barks when a kernel user access causes this condition, and that _can_ happen. For example, if a pointer passed into a system call is "0xfffffffc" and the kernel access 4 bytes offset from that pointer. Just handle such faults normally via the exception entries. Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
extable.c | ||
fault_32.c | ||
fault_64.c | ||
gup.c | ||
highmem.c | ||
hugetlbpage.c | ||
hypersparc.S | ||
init_32.c | ||
init_64.c | ||
init_64.h | ||
io-unit.c | ||
iommu.c | ||
leon_mm.c | ||
Makefile | ||
srmmu.c | ||
srmmu.h | ||
srmmu_access.S | ||
swift.S | ||
tlb.c | ||
tsb.c | ||
tsunami.S | ||
ultra.S | ||
viking.S |