Re: stack smashing detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 SCSI2SD

Exception 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?



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux