Re: RFC: remove set_fs for m68k

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Linus,

having run stress tests on a kernel with Al Viro's signal handling fixes
applied for the past two days with no further errors, I am now quite
confident that the format error I saw in resume_userspace() and a bus
error in setup_frame() were caused by multiple pending signals, and the
resulting stack mangling that Al's patches fix.

I'll try to conclusively prove that for the setup_frame() case, but for
the sake of bringing Christoph's set_fs patches for m68k to a close,
I'll go with this assumption.

Al: I'm still poring over some of the subtleties of your patch series,
but you can add my Tested-by at least (030 only).

Cheers,

    Michael


Am 24.08.21 um 05:59 schrieb Linus Torvalds:
> On Sun, Aug 22, 2021 at 12:34 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Got this overnight:
>>
>>> [536154.200000] *** FORMAT ERROR ***   FORMAT=0
>>> [536154.210000] Current process id is 4656
>>> [536154.230000] BAD KERNEL TRAP: 00000000
>>> [536154.240000] Modules linked in: atari_scsi ne 8390p [last unloaded: atari_scsi]
>>> [536154.260000] PC: [<00002a8c>] resume_userspace+0x14/0x16
>>> [536154.270000] SR: 2208  SP: 977bd1be  a2: 8009b5e8
>>> [536154.290000] d0: 8009b5e8    d1: cfcfcfcf    d2: 00000000    d3: ffffffff
>>> [536154.300000] d4: 00000000    d5: 00000000    a0: 8008a108    a1: 8009b7df
>>> [536154.320000] Process savelog (pid: 4656, task=e49aa246)
>>> [536154.330000] Frame format=0
>>> [536154.340000] Stack from 00cc5fa4:
>>> [536154.340000]         02088004 3666b008 1c0eb209 007eb5e8 8006a2d0 efaec378 8004366c 61ff61ff
>>> [536154.340000]         8006a2d4 8006a2d2 00000000 030dfffb 0044fffa 0e000000 fffa1a00 fffa1c00
>>> [536154.340000]         fffa1e00 fffb0e40 fffb0e80 00049b66 00000040 005f5800 00000001
> Strange. If I read that stack frame correctly, that seems to be an
> exception frame of type 0xb ("Long Bus Cycle").
>
> Plus the frame content is then apparently corrupted enough that the
> rte causes an exception on trying to restore it.
>
> None of which makes sense or seems to have much at all to do with any
> of these patches. Yes, we mess with the exception frame, but only for
> fork(), and while "copy_process()" doesn't set any frame type, I see
> only two cases:
>
>  - the kernel thread one does a "memset()" to clear it, so you should
> end up with frame type 0
>
>  - the user thread case copies the original frame format (which I
> think is just the system call frame from the TRAP instruction).
>
> Are you 100% sure your hardware is stable?
>
>                   Linus