From: Finn Thain <fthain@linux-m68k.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Guenter Roeck <linux@roeck-us.net>,
linux-m68k@lists.linux-m68k.org
Subject: Re: spinlock recursion when running q800 emulation in qemu
Date: Mon, 18 Mar 2024 20:31:52 +1100 (AEDT) [thread overview]
Message-ID: <627480db-d871-8226-9028-e768512b1917@linux-m68k.org> (raw)
In-Reply-To: <284ada62-c1bd-2321-ae18-27a315c56c33@gmail.com>
On Mon, 18 Mar 2024, Michael Schmitz wrote:
> Am 15.03.2024 um 20:24 schrieb Finn Thain:
> >
> > On Fri, 15 Mar 2024, Michael Schmitz wrote:
> >
> >>
> >> No luck with whatever I tried around signals, cache maintenance and
> >> mm.
> >>
> >> The 'BUG: Bad rss-counter state' message suggests we're freeing the
> >> same page ranges twice, sometimes in many cases. I cannot quite see
> >> how preempting the kernel on interupt return would cause this. Signal
> >> forcing process exit but process exiting before signal is received
> >> due to preemption? But skipping preemption when a signal is pending
> >> did not change anything in my tests...
> >>
> >> Running out of ideas here, sorry.
> >>
> >
> > FWIW, I found that the failure mode (with CONFIG_PREEMPT) changed
> > significantly after I disabled hard irqs in do_IRQ() using the patch I
> > sent on the 8th. In three stress-ng test runs, I got a soft lockup, a
> > WARN from set_fc() and some CONFIG_DEBUG_LIST failures...
>
> Yes, I do see that with your patch, too. I still see the old 'table
> already free' bug, though.
>
> As far as I can see, the set_fc warning is from access_error040 and is
> part of the access error exception that is taken in interrupt context.
>
> The question is basically - why is __free_one_page() called from
> interrupt context? Did that also happen before Geert's preemption patch?
>
I did see that set_fc() warning during the mmap stress testing I did a few
years ago. The example below comes from 5.18.0-rc7-mac-00006-g210e04ff7681
but a lot has changed since then and it may not be relevant. I stopped
doing those tests when Al Viro fixed the bug I was chasing. When I get
time I shall fire up a Quadra and try again with v6.8.
stress-ng: info: [116] dispatching hogs: 1 mmap
[ 1673.480000] ------------[ cut here ]------------
[ 1673.480000] WARNING: CPU: 0 PID: 159 at ./arch/m68k/include/asm/processor.h:91 buserr_c+0x59a/0x99a
[ 1673.480000] Modules linked in:
[ 1673.480000] CPU: 0 PID: 159 Comm: Not tainted 5.18.0-rc7-mac-00006-g210e04ff7681 #2
[ 1673.480000] Stack from 00a13dec:
[ 1673.480000] 00a13dec 0046b224 0046b224 00000000 00a13e08 003d7e16 0046b224 00a13e1c
[ 1673.480000] 0001c1b4 00000000 00a13e94 b6db6eaa 00a13e48 0001c240 00461323 0000005b
[ 1673.480000] 0000678c 00000009 00000000 00000000 00000505 b6db6db6 db6db6db 00a13e88
[ 1673.480000] 0000678c 00461323 0000005b 00000009 00000000 00000000 00989680 00000004
[ 1673.480000] 003d6a82 0000000c 003dbb98 00a1f780 004b0c0c 000496dc 00077359 00a13f0c
[ 1673.480000] 00002bcc 00a13e94 00010000 00000000 00989680 00000004 003d6a82 b6db6db6
[ 1673.480000] Call Trace: [<003d7e16>] dump_stack+0x10/0x16
[ 1673.480000] [<0001c1b4>] __warn+0xc6/0xe8
[ 1673.480000] [<0001c240>] warn_slowpath_fmt+0x6a/0x76
[ 1673.480000] [<0000678c>] buserr_c+0x59a/0x99a
[ 1673.480000] [<0000678c>] buserr_c+0x59a/0x99a
[ 1673.480000] [<003d6a82>] _printk+0x0/0x16
[ 1673.480000] [<003dbb98>] down_read+0x0/0xdc
[ 1673.480000] [<000496dc>] __irq_wake_thread+0x0/0x44
[ 1673.480000] [<00077359>] ___bpf_prog_run+0x18b/0x20e4
[ 1673.480000] [<00002bcc>] buserr+0x20/0x28
[ 1673.480000] [<00010000>] LP1CONT1+0x4a/0x7c
[ 1673.480000] [<003d6a82>] _printk+0x0/0x16
[ 1673.480000] [<00050005>] dma_coherent_ok+0x1d/0xb8
[ 1673.480000] [<00012704>] tblpre+0x594/0x700
[ 1673.480000] [<0001c1d6>] warn_slowpath_fmt+0x0/0x76
[ 1673.480000] [<00040e08>] account_system_time+0x74/0xca
[ 1673.480000] [<0004113e>] account_process_tick+0x30/0xb0
[ 1673.480000] [<00010000>] LP1CONT1+0x4a/0x7c
[ 1673.480000] [<00053a6e>] update_process_times+0x36/0xae
[ 1673.480000] [<00060bdc>] legacy_timer_tick+0x64/0x6c
[ 1673.480000] [<00008fa4>] via_timer_handler+0x1e/0x24
[ 1673.480000] [<00049756>] __handle_irq_event_percpu+0x36/0xd8
[ 1673.480000] [<00002600>] name_to_dev_t+0x1a4/0x3f8
[ 1673.480000] [<003d9d40>] yield_to+0x88/0x8c
[ 1673.480000] [<0004980c>] handle_irq_event_percpu+0x14/0x52
[ 1673.480000] [<0004986c>] handle_irq_event+0x22/0x36
[ 1673.480000] [<0004cf1a>] handle_simple_irq+0x4e/0x7c
[ 1673.480000] [<00048f3e>] generic_handle_irq+0x3c/0x4a
[ 1673.480000] [<00008e3c>] via1_irq+0x7e/0x96
[ 1673.480000]
[ 1673.480000] ---[ end trace 0000000000000000 ]---
next prev parent reply other threads:[~2024-03-18 9:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 17:58 spinlock recursion when running q800 emulation in qemu Guenter Roeck
2024-03-05 0:33 ` Finn Thain
2024-03-05 0:48 ` Michael Schmitz
[not found] ` <fcb506f2-523d-4efc-ae3d-fe3c79c6f09e@gmail.com>
2024-03-05 0:58 ` Guenter Roeck
2024-03-05 1:06 ` Michael Schmitz
2024-03-06 7:14 ` Michael Schmitz
2024-03-06 8:30 ` Brad Boyer
2024-03-06 23:13 ` Finn Thain
2024-03-06 23:46 ` Guenter Roeck
2024-03-07 23:35 ` Finn Thain
2024-03-06 23:42 ` Michael Schmitz
2024-03-06 23:52 ` Finn Thain
2024-03-08 0:20 ` Michael Schmitz
2024-03-08 0:56 ` Finn Thain
2024-03-08 8:06 ` Michael Schmitz
2024-03-08 9:15 ` Finn Thain
2024-03-08 9:33 ` Finn Thain
2024-03-08 20:14 ` Michael Schmitz
2024-03-09 5:02 ` Finn Thain
2024-03-09 20:56 ` Michael Schmitz
2024-03-09 22:18 ` Finn Thain
2024-03-11 7:06 ` Michael Schmitz
2024-03-11 8:35 ` Finn Thain
2024-03-12 0:51 ` Michael Schmitz
2024-03-12 7:59 ` Geert Uytterhoeven
2024-03-12 20:14 ` Michael Schmitz
2024-03-13 0:16 ` Michael Schmitz
2024-03-13 4:39 ` Preemption (was: Re: spinlock recursion when running q800 emulation in qemu) Michael Schmitz
2024-03-13 4:40 ` spinlock recursion when running q800 emulation in qemu Finn Thain
2024-03-13 5:34 ` Michael Schmitz
2024-03-14 0:59 ` Michael Schmitz
2024-03-15 4:32 ` Michael Schmitz
2024-03-15 7:24 ` Finn Thain
2024-03-18 6:24 ` Michael Schmitz
2024-03-18 9:31 ` Finn Thain [this message]
2024-03-20 1:00 ` Michael Schmitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=627480db-d871-8226-9028-e768512b1917@linux-m68k.org \
--to=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux@roeck-us.net \
--cc=schmitzmic@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox