aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2009-02-02 22:08:15 -0800
committerDavid S. Miller <davem@davemloft.net>2009-02-02 22:08:15 -0800
commiteeabac7386ca13bfe1a58afeb04326a9e1a3a20e (patch)
tree9e15ca81917df4c980b29c54091f909bdc868138 /README
parent802c64b310e5b9dfda6cb50b850b962ed96a9e81 (diff)
sparc64: Validate kernel generated fault addresses on sparc64.
In order to handle all of the cases of address calculation overflow properly, we run sparc 32-bit processes in "address masking" mode when running on a 64-bit kernel. Address masking mode zeros out the top 32-bits of the address calculated for every load and store instruction. However, when we're in privileged mode we have to run with that address masking mode disabled even when accessing userspace from the kernel. To "simulate" the address masking mode we clear the top-bits by hand for 32-bit processes in the fault handler. It is the responsibility of code in the compat layer to properly zero extend addresses used to access userspace. If this isn't followed properly we can get into a fault loop. Say that the user address is 0xf0000000 but for whatever reason the kernel code sign extends this to 64-bit, and then the kernel tries to access the result. In such a case we'll fault on address 0xfffffffff0000000 but the fault handler will process that fault as if it were to address 0xf0000000. We'll loop faulting forever because the fault never gets satisfied. So add a check specifically for this case, when the kernel is faulting on a user address access and the addresses don't match up. This code path is sufficiently slow path, and this bug is sufficiently painful to diagnose, that this kind of bug check is warranted. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions