Hi Finn,
yes, that would explain that.
Using a start address of badpage-4 and path '/tmp' or '/temp' in order
to use either the movesw or movesb branches of the code (and force a
fault on the first byte in the movesw case), I see no more Oops. Still
have to test forcing the fault on the second byte of a movesw (making it
a misaligned access again).
Cheers,
Michael
On 26/04/24 13:00, Finn Thain wrote:
On Fri, 26 Apr 2024, Michael Schmitz wrote:
Not sure you noticed this - the 040 passed __clear_user without fault.
We managed to test this one without meaning to. Exception handling in
there appears to work OK (for the cases we're testing).
No idea why you have the __clear_user call occur within
__generic_copy_to_user - it does not appear in my disassembly.
I'm afraid I neglected to mention that I added the patch below in order to
exercise that code path.
diff --git a/arch/m68k/lib/uaccess.c b/arch/m68k/lib/uaccess.c
index ef761fc10981..1c9a24a0b554 100644
--- a/arch/m68k/lib/uaccess.c
+++ b/arch/m68k/lib/uaccess.c
@@ -58,6 +58,8 @@ unsigned long __generic_copy_to_user(void __user *to, const void *from,
{
unsigned long tmp, res;
+ __clear_user(to, n);
+
asm volatile ("\n"
" tst.l %0\n"
" jeq 5f\n"
