Re: spinlock recursion when running q800 emulation in qemu

Michael Schmitz
2024-03-13T00:16:33Z

Hi Geert,

On 12/03/24 20:59, Geert Uytterhoeven wrote:
> On Tue, Mar 12, 2024 at 1:51 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> On 11/03/24 21:35, Finn Thain wrote:
>>> I think spin_lock() reduces to preempt_disable() on UP.
>>> In include/linux/spinlock_api_up.h it says,
>>>
>>> /*
>>> * In the UP-nondebug case there's no real locking going on, so the
>>> * only thing we have to do is to keep the preempt counts and irq
>>> * flags straight, to suppress compiler warnings of unused lock
>>> * variables, and to add the proper checker annotations:
>>> */
>> That's only true in the debug case - there, preempt_disable() is used
>> inside the spin loop. But m68k is one of the last CONFIG_PREEMPT_NONE
>> archs AFAIR, and preempt_disable() reduces to barrier() on those.
> M68k does have experimental preempt support. I have been running
> that for the last 5 months. Works fine most of the time, except for
> the one BUG[1] that happens every 10 boots or so.
>
> [1] https://lore.kernel.org/all/CAMuHMdUQ72KOPw5vxNfhjoTR-SsaELeKneBmyQPYEWa_o5OZZA@mail.gmail.com

NB: the Kconfig hunk no longer applies, it now should look like this:

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 4b3e93cac723..0c4b5180df1d 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -10,7 +10,6 @@ config M68K
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if M68K_NONCOHERENT_DMA
select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
-       select ARCH_NO_PREEMPT if !COLDFIRE
select ARCH_USE_MEMTEST if MMU_MOTOROLA
select ARCH_WANT_IPC_PARSE_VERSION
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK

(HAS_DMA -> M68K_NONCOHERENT_DMA)

Runs fine on ARAnyM with a bit of VM stress testing using
PREEMPT_VOLUNTARY. After a bit of looping (init=/sbin/reboot), fails
spectacularly with not finding any root filesystem to mount when using
full preempt.

Trying to boot a full system, I see the 'table already freed' panic on
the first go.

Running a stack-ng stack-fill stressor triggered the panic, too. I'll
see how reliable that is.

Cheers,

Michael

>
> Gr{oetje,eeting}s,
>
> Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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