From: David S. Miller Date: Wed, 7 May 2014 04:27:37 +0000 (-0700) Subject: sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses. X-Git-Tag: omap-for-v3.16/fixes-against-rc1~145^2~3 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e5c460f46ae7ee94831cb55cb980f942aa9e5a85;p=pandora-kernel.git sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses. 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 --- Reading git-diff-tree failed