Re: [PATCH RFC v2 1/2] m68k: Handle __generic_copy_to_user faults more carefully

[Michael Schmitz <schmitzmic@gmail.com>]

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"