Hi Stan, Am 02.02.2023 um 07:51 schrieb Michael Schmitz:
But since we're touching on copy_to_user() here - the 'remove set_fs' patch set by Christoph Hellwig refactored the m68k inline helpers around July 2021. Can you test a kernel prior to those patches (5.15-rc2)?That's a lot of work on a 030 Mac - have you tried to reproduce this on any kind of emulator?I haven't seen the error in QEMU.I suppose one difference between your 030 and 040 Macs might be the amount of RAM available. I wonder if this bug results from a combination of 030 MMU and memory pressure, or 030 MMU only.For some reason, the error seems to happen only with 68030 systems, regardless of processor speed or memory: PB 170 : 68030, 25 MHz, 8 MiB, external SCSI2SD Mac IIci : 68030, 25 MHz, 80 MiB, internal SCSI2SD SE/30 : 68030, 16 MHz, 128 MiB, external SCSI2SD PB 550c : 68040, 33 MHz, 36 MiB, external SCSI2SD Centris 650 : 68040, 25 MHz, 136 MiB, internal SCSI2SDException handling in copy_to_user() and the related bits in 030 page fault handling might need another look in then...
Seeing Finn's report that Al Viro's VM_FAULT_RETRY fix may have solved his task corruption troubles on 040, I just noticed that I probably misunderstood how Al's patch works.
Botching up a fault retry and carrying on may well leave the page tables in a state where some later access could go to the wrong page and manifest as user space corruption. Could you try Al's patch 4 (m68k: fix livelock in uaccess) to see if this helps?
Cheers, Michael