Re: stack smashing detected
On 2/3/23 4:39 PM, Finn Thain wrote: Hi Finn, > On Wed, 1 Feb 2023, Stan Johnson wrote: > >> >> After logging the start and end of each script, I see that the "stack >> smashing detected" error often happens while running >> "/etc/rcS.d/S01mountkernfs.sh" (/etc/init.d/mountkernfs.sh). I'll try to >> isolate it to a particular command. >> > > That brings to mind some other unresolved initscript failures, also > involving 68030, which were accompanied by "page allocation failure". > > But it's hard to blame "stack smashing detected" on a page allocation > failure since the latter always produces a very noisy splat in the kernel > messages. > > Have you reproduced the error with Debian's kernel package? Yes, but with the previous Debian kernel (I will try with the latest kernel on the IIci to confirm). > > If not, please refer to private correspondence from me dated 10 December > 2022 regarding setting up /etc/initramfs-tools so as to produce a suitably > small initramfs. I did see that, but I don't think it's relevant for my current tests -- to save time, I'm using a custom kernel, with no initramfs and no modules (6.1.8, though I think 6.1.9 is out). > > To save time, I recommend using QEMU and an up-to-date Debian/m68k SID > virtual machine to produce the vmlinux and initrd files needed for use > with Penguin on your slower machines. > AFAIK, the initrd must be created on the system that is using the initrd (or an identical system, at least that was the response I received a while back when I was unsuccessfully trying to use the initrd that ships on the Debian install CD). I have confirmed that the stack smashing also occurs on an SE/30 using my custom 6.1.8 kernel and the latest Debian SID. While that does not rule out a hardware problem on my IIci or SE/30, it would be unlikely that I would have the same problem on both systems. I'll proceed with testing Debian's latest default kernel on the IIci (with Debian's modules and an initrd created on the IIci), then I'll investigate either isolating the offending executable (apparently in /etc/rcS.d/S01mountkernfs.sh) or I'll check whether a git bisect might identify anything interesting, though I first need to locate the latest mainline kernel that doesn't have the problem and the earliest one that does. It's possible that QEMU (I'm using 7.2) doesn't see the problem because it emulates a 68040 for q800 and virt; so far I've only seen the issue on 68030 systems. -Stan
Re: stack smashing detected
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? Cheers, Michael
Debian initramfs/initrd, was Re: stack smashing detected
On Sun, 5 Feb 2023, Stan Johnson wrote: > > > > To save time, I recommend using QEMU and an up-to-date Debian/m68k SID > > virtual machine to produce the vmlinux and initrd files needed for use > > with Penguin on your slower machines. > > > > AFAIK, the initrd must be created on the system that is using the initrd > (or an identical system, at least that was the response I received a > while back when I was unsuccessfully trying to use the initrd that ships > on the Debian install CD). If that was true, how could Debian ship a single initrd that works on Atari, Amiga, Mac etc.? They could not. If you boot a random Debian/m68k rootfs with a random Debian/m68k vmlinux/initrd combination, and if you need a kernal module at some point, then your random rootfs must contain the modules that match your random kernel binary (probably not going to work). If you never need to load a module, perhaps because the important ones all got loaded from the initrd, then all you need is a valid vmlinux/initrd combination and the rootfs is not relevant. When you need to generate a valid Debian/m68k vmlinux/initrd combination that is also current, then you'll need a Debian/m68k system that is current. The quickest way to get it is an emulator. When you need a small initrd, because of RAM limitations, you'll need to customize your initrd for your hardware using /etc/initramfs-tools (as mentioned). If you succeed, you'll get an initrd that is missing all the modules for all the hardware that you don't own, which saves RAM. It doesn't matter what system generates that initrd (could be a build farm).
Re: Debian initramfs/initrd, was Re: stack smashing detected
On Mon, 2023-02-06 at 09:29 +1100, Finn Thain wrote: > On Sun, 5 Feb 2023, Stan Johnson wrote: > > > > > > > To save time, I recommend using QEMU and an up-to-date Debian/m68k SID > > > virtual machine to produce the vmlinux and initrd files needed for use > > > with Penguin on your slower machines. > > > > > > > AFAIK, the initrd must be created on the system that is using the initrd > > (or an identical system, at least that was the response I received a > > while back when I was unsuccessfully trying to use the initrd that ships > > on the Debian install CD). > > If that was true, how could Debian ship a single initrd that works on > Atari, Amiga, Mac etc.? They could not. You cannot use the initrd that's on the debian-installer medium because it boots directly into the installer. It's not a regular initrd. That's completely independent of the architecture/sub-architecture in use. > When you need to generate a valid Debian/m68k vmlinux/initrd combination > that is also current, then you'll need a Debian/m68k system that is > current. The quickest way to get it is an emulator. Correct. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Debian initramfs/initrd, was Re: stack smashing detected
On 2/5/23 4:18 PM, John Paul Adrian Glaubitz wrote: > On Mon, 2023-02-06 at 09:29 +1100, Finn Thain wrote: >> ... > >> When you need to generate a valid Debian/m68k vmlinux/initrd combination >> that is also current, then you'll need a Debian/m68k system that is >> current. The quickest way to get it is an emulator. > > Correct. > ... Adrian and Finn, Thanks, that's good to know. FYI, On an SE/30 with 128 MiB memory, the latest Debian SID kernel (vmlinux-6.1.0-2-m68k), using Debian SID modules, and with initrd-6.1.0-2-m68k built on the SE/30, hangs after the initial "ABCFGHIJK" (I tried it twice). On a Mac IIci with 80 MiB memory, using the same setup, except with the initrd-6.1.0-2-m68k built in QEMU, the system boots and there were no stack smashing errors (only one boot, though, and it took over 30 minutes to reach multiuser). The NIC (mac8390: MacCon Ethernet, type asante) wasn't seen. So I guess it's likely that I never booted an unmodified Debian SID kernel on the IIci, but instead used a modified kernel with the NIC added and obvious things (such as USB, Firewire, wireless, etc.) removed. And my 6.1.8 kernel is further modified to disable modules and initrd, and I apparently also disabled other things such as polling of the CD drive (the activity light no longer blinks every two seconds). Booting my custom 6.1.8 kernel, I see stack smashing again, so it's possible that my choice of kernel options is making the stack smashing more likely to occur, but there's not enough data at this point to make that conclusion. I'll send an update after I add the patch that Michael mentioned. thanks -Stan
Re: Debian initramfs/initrd, was Re: stack smashing detected
Hi Stan,
On Mon, Feb 6, 2023 at 4:42 AM Stan Johnson wrote:
> On an SE/30 with 128 MiB memory, the latest Debian SID kernel
> (vmlinux-6.1.0-2-m68k), using Debian SID modules, and with
> initrd-6.1.0-2-m68k built on the SE/30, hangs after the initial
> "ABCFGHIJK" (I tried it twice).
If you get to "K", you're almost at the end of arch/m68k/kernel/head.S,
and it is very likely the kernel C-code actually started.
Do you get any output using "debug earlyprintk" on the kernel command
line?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
