public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Finn Thain <fthain@linux-m68k.org>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-m68k@lists.linux-m68k.org
Subject: Preemption (was: Re: spinlock recursion when running q800 emulation in qemu)
Date: Wed, 13 Mar 2024 17:39:32 +1300	[thread overview]
Message-ID: <66e2c2c2-4d23-33d4-0963-6868a746f2ad@gmail.com> (raw)
In-Reply-To: <0c7b96d2-1cf1-4fc1-876e-8e3bc859a1c5@gmail.com>

Hi Geert,

Am 13.03.2024 um 13:16 schrieb Michael Schmitz:
> 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.

That's actually pretty reliable - running stress-ng --stack 2 
--stack-fill two or three times gets me a panic (on a fast Intel system).

Running full preemption on the PowerBook instance, the older one of my 
disk images boots OK (sysvinit based), the newer one (systemd IIRC) 
cheerfully throws endless Oops of this kind:

> Unable to handle kernel NULL pointer dereference at virtual address b90995fb
> Oops: 00000000
> Modules linked in:
> PC: [<000de1d6>] del_page_from_free_list+0x16/0x46
> SR: 2700  SP: 3e9c0737  a2: 00f34610
> d0: 00000000    d1: 0054491c    d2: 0000000b    d3: 00000000
> d4: 0000000f    d5: 00000000    a0: 0054491c    a1: 00495dd0
> Process vol_id (pid: 1198, task=54e40596)
> Frame format=7 eff addr=00000104 ssw=0405 faddr=00000104
> wb 1 stat/addr/data: 0000 00000000 00000000
> wb 2 stat/addr/data: 0000 00000000 00000000
> wb 3 stat/addr/data: 0085 00000104 00495dd0
> push data: 00000000 00000000 00000000 00000000
> Stack from 0482fbc4:
>         0076343c 000df4ce 0054491c 00495d78 00000000 00000000 00000801 00000000
>         00000000 00002000 0076343c 00495d78 000df8de 0482e000 0482fd06 0000001e
>         0054491c 00544920 00000000 00495f84 00002700 00000058 00000058 00495d78
>         000dfb70 00495d78 00000000 00000000 00000801 0076343c 00763464 00152c40
>         00000000 00112cc0 00000000 00000000 000b493c 0482fd06 000df974 01023764
>         0032d0e8 00dd7400 00f1fe58 00000049 64560000 00010000 0000f000 00000a00
> Call Trace: [<000df4ce>] __rmqueue_pcplist+0x198/0x316
>  [<00002000>] _start+0x0/0x8
>  [<000df8de>] zone_watermark_fast.isra.112+0x0/0x96
>  [<00002700>] resume_userspace+0xa/0x16
>  [<000dfb70>] get_page_from_freelist+0x1fc/0x632
>  [<00152c40>] ext4_ext_convert_to_initialized+0x50c/0x534
>  [<00112cc0>] simple_transaction_get+0x52/0x98
>  [<000b493c>] filemap_add_folio+0x0/0x9e
>  [<000df974>] get_page_from_freelist+0x0/0x632
>  [<0032d0e8>] xa_load+0x0/0x76
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<0000f000>] NEVEN+0xd8/0xec
>  [<000df7d2>] prepare_alloc_pages.isra.110+0x70/0x84
>  [<000e0f4e>] __alloc_pages+0xa8/0x6b2
>  [<00152c40>] ext4_ext_convert_to_initialized+0x50c/0x534
>  [<00112cc0>] simple_transaction_get+0x52/0x98
>  [<000b493c>] filemap_add_folio+0x0/0x9e
>  [<0032d0e8>] xa_load+0x0/0x76
>  [<00004ec2>] buserr_c+0x10c/0x3e6
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<0032cf2a>] xas_load+0x1e/0x60
>  [<0032cf0c>] xas_load+0x0/0x60
>  [<0032d150>] xa_load+0x68/0x76
>  [<000e1a46>] __folio_alloc+0x1c/0x2a
>  [<00152cc0>] ext4_ext_index_trans_blocks+0x0/0x3a
>  [<000bace0>] page_cache_ra_unbounded+0xb0/0x140
>  [<00112cc0>] simple_transaction_get+0x52/0x98
>  [<00010fff>] X_OPERR+0x3/0x40
>  [<000b4c24>] filemap_get_pages+0x24a/0x4e0
>  [<00008000>] nvram_proc_read+0x4c/0x31a
>  [<001000f0>] fiemap_prep+0x6c/0xc2
>  [<000f0000>] vfs_writev+0x2c/0x16e
>  [<001c0000>] bio_may_exceed_limits.isra.35+0x8/0x54
>  [<000b4f66>] filemap_read+0xac/0x30c
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00008000>] nvram_proc_read+0x4c/0x31a
>  [<00008000>] nvram_proc_read+0x4c/0x31a
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00007000>] atari_tt_hwclk+0x16c/0x2fc
>  [<00003000>] arch_ptrace+0xa6/0x24a
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<001b5716>] blkdev_read_iter+0x118/0x138
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00008000>] nvram_proc_read+0x4c/0x31a
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<000f0a68>] vfs_read+0xcc/0x128
>  [<00008000>] nvram_proc_read+0x4c/0x31a
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<000f0dfc>] ksys_read+0x4a/0x86
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<0000fff6>] TWOMAIN+0x70/0x80
>  [<000f0e4a>] sys_read+0x12/0x18
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<0000269a>] syscall+0x8/0xc
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<00010000>] TWOMAIN+0x7a/0x80
>  [<0000c00c>] ATANTBL+0x114/0x800
>
> Code: 202f 0010 2668 0004 2268 0008 2749 0004 <228b> 217c 0000 0100 0004 217c 0000 0122 0008 0068 0080 001a 42a8 0014 2200 e589
> Disabling lock debugging due to kernel taint
> note: vol_id[1198] exited with irqs disabled
> note: vol_id[1198] exited with preempt_count 3

(killed ARAnyM after 26 of those).

Booted OK on the next boot, produced a 'table already free' panic after 
three or four runs of the stack-fill stress test.

Cheers,

	Michael


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

  reply	other threads:[~2024-03-13  4:39 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                                 ` Michael Schmitz [this message]
2024-03-13  4:40                                 ` 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
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=66e2c2c2-4d23-33d4-0963-6868a746f2ad@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux@roeck-us.net \
    /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