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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,

Am 25.04.2024 um 18:32 schrieb Finn Thain:
>>> This oops indicates that we are going to need the final NOP that was
>>> in the first version of your patch. My test program seems inadequate
>>> to show that it is safe to omit that NOP -- we would need a test which
>>> doesn't jump over the MOVES.B.
>>
>> We'd need a test using any number of longword moves expected to succeed,
>> followed by a byte move which is expected to fault. The current test
>> would attempt to do a byte move, but faults during the longword moves.
>>
>> This requires running the test program in a directory whose absolute
>> path is a multiple of four characters long, and setting the start
>> address for the getcwd test accordingly, so the newline at the end of
>> the string is the single byte left to copy. Does that make sense?
>>
>
> Yes (I take it you meant NUL instead of LF). But my concern was that the

Yes, my bad ...

> test program passes a pointer like 0xc0029000 - 1. That means the final
> byte will land on a word that already faulted. I'll need to add a new test
> that passes a pointer like 0xc0029000 - 5.

That's what I meant to say, yes.

>> Incidentally - what is the path this tests is run in? Any path longer
>> than five characters (including the newline) would have to had looped
>> back to the first movel, and faulted there?
>>
>
> It was /tmp.

Right - so if I'm right, running the test in /root would exercise the 
movesw path, and fault on the movew. Using /var/tmp would loop back once 
to repeat the movesl, and likely fault on the movel there.

>> As you said before - we'd need to know a lot more about
>> microarchitectural details here.
>>
>
> It's hard to be certain. We just have to experiment until we find
> something that works on the CPUs we can test.

Right - I'll try a few of these ideas on my 030.

Cheers,

	Michael