From: Waiman Long <llong@redhat.com>
To: Guenter Roeck <linux@roeck-us.net>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
Boqun Feng <boqun.feng@gmail.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>
Subject: Re: [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock_t.
Date: Mon, 25 Nov 2024 14:33:04 -0500 [thread overview]
Message-ID: <5d269249-afd1-44f5-8faf-9ac11d9a3beb@redhat.com> (raw)
In-Reply-To: <72991b83-173e-492e-a4aa-5049304c1bd0@roeck-us.net>
On 11/25/24 2:23 PM, Guenter Roeck wrote:
> On 11/25/24 10:12, Sebastian Andrzej Siewior wrote:
>> On 2024-11-25 09:59:09 [-0800], Guenter Roeck wrote:
>>> On 11/25/24 09:43, Sebastian Andrzej Siewior wrote:
>>>> On 2024-11-25 09:01:33 [-0800], Guenter Roeck wrote:
>>>>> Unfortunately it doesn't make a difference.
>>>>
>>>> stunning. It looks like the exact same error message.
>>>>
>>>
>>> I think it uses
>>>
>>> #define spin_lock_irqsave(lock, flags) \
>>> do { \
>>> raw_spin_lock_irqsave(spinlock_check(lock), flags); \
>>> } while (0)
>>>
>>> from include/linux/spinlock.h, meaning your patch doesn't really
>>> make a difference.
>>
>> The difference comes from DEFINE_SPINLOCK vs DEFINE_RAW_SPINLOCK. There
>> is the .lock_type init which goes from LD_WAIT_CONFIG to LD_WAIT_SPIN.
>> And this is all it matters.
>>
>
> Ah, now I get it. Thanks for the explanation. And it turns out my log
> was wrong.
> I must have taken it from the old image. Sorry for that.
>
> That specific backtrace isn't seen anymore. But there is another one.
>
> [ 1.779653] =============================
> [ 1.779860] [ BUG: Invalid wait context ]
> [ 1.780139] 6.12.0+ #1 Not tainted
> [ 1.780394] -----------------------------
> [ 1.780600] swapper/0/1 is trying to lock:
> [ 1.780824] 0000000001b68888 (cpu_map_lock){....}-{3:3}, at:
> map_to_cpu+0x10/0x80
> [ 1.781393] other info that might help us debug this:
> [ 1.781624] context-{5:5}
> [ 1.781838] 3 locks held by swapper/0/1:
> [ 1.782055] #0: fffff800042b90f8 (&dev->mutex){....}-{4:4}, at:
> __driver_attach+0x80/0x160
> [ 1.782345] #1: fffff800040f2c18
> (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0xa0/0x6e0
> [ 1.782632] #2: fffff800040f2ab0
> (&irq_desc_lock_class){....}-{2:2}, at: __setup_irq+0xc8/0x6e0
> [ 1.782912] stack backtrace:
> [ 1.783172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 6.12.0+ #1
> [ 1.783498] Call Trace:
> [ 1.783734] [<00000000004e31d0>] __lock_acquire+0xa50/0x3160
> [ 1.783971] [<00000000004e63e8>] lock_acquire+0xe8/0x340
> [ 1.784191] [<00000000010f0dbc>] _raw_spin_lock_irqsave+0x3c/0x80
> [ 1.784417] [<000000000043ed90>] map_to_cpu+0x10/0x80
> [ 1.784633] [<000000000042b2b8>] sun4u_irq_enable+0x18/0x80
> [ 1.784854] [<00000000004fb6b4>] irq_enable+0x34/0xc0
> [ 1.785069] [<00000000004fb7b8>] __irq_startup+0x78/0xe0
> [ 1.785287] [<00000000004fb8f0>] irq_startup+0xd0/0x1a0
> [ 1.785503] [<00000000004f85b4>] __setup_irq+0x5f4/0x6e0
> [ 1.785726] [<00000000004f8754>] request_threaded_irq+0xb4/0x1a0
> [ 1.785950] [<0000000000439930>] power_probe+0x70/0xe0
> [ 1.786165] [<0000000000c13a68>] platform_probe+0x28/0x80
> [ 1.786382] [<0000000000c11178>] really_probe+0xb8/0x340
> [ 1.786599] [<0000000000c115a4>] driver_probe_device+0x24/0xe0
> [ 1.786820] [<0000000000c117cc>] __driver_attach+0x8c/0x160
> [ 1.787039] [<0000000000c0ef74>] bus_for_each_dev+0x54/0xc0
>
> After replacing cpu_map_lock with a raw spinlock, I get:
>
> [ 2.015140] =============================
> [ 2.015247] [ BUG: Invalid wait context ]
> [ 2.015419] 6.12.0+ #1 Not tainted
> [ 2.015564] -----------------------------
> [ 2.015668] swapper/0/1 is trying to lock:
> [ 2.015791] fffff80004870610 (&mm->context.lock){....}-{3:3}, at:
> __schedule+0x410/0x5b0
> [ 2.016306] other info that might help us debug this:
> [ 2.016451] context-{5:5}
> [ 2.016539] 3 locks held by swapper/0/1:
> [ 2.016652] #0: 0000000001d11f38 (key_types_sem){++++}-{4:4}, at:
> __key_create_or_update+0x5c/0x4c0
> [ 2.016934] #1: 0000000001d1b850
> (asymmetric_key_parsers_sem){++++}-{4:4}, at:
> asymmetric_key_preparse+0x18/0xa0
> [ 2.017197] #2: fffff8001f811a98 (&rq->__lock){-.-.}-{2:2}, at:
> __schedule+0xdc/0x5b0
> [ 2.017412] stack backtrace:
> [ 2.017551] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 6.12.0+ #1
> [ 2.017800] Call Trace:
> [ 2.017910] [<00000000004e31d0>] __lock_acquire+0xa50/0x3160
> [ 2.018062] [<00000000004e63e8>] lock_acquire+0xe8/0x340
> [ 2.018192] [<00000000010f0dbc>] _raw_spin_lock_irqsave+0x3c/0x80
> [ 2.018341] [<00000000010e5050>] __schedule+0x410/0x5b0
> [ 2.018469] [<00000000010e5ae4>] schedule+0x44/0x1c0
> [ 2.018591] [<00000000010f0684>] schedule_timeout+0xa4/0x100
> [ 2.018730] [<00000000010e668c>] __wait_for_common+0xac/0x1a0
> [ 2.018869] [<00000000010e6878>] wait_for_completion_state+0x18/0x40
> [ 2.019022] [<000000000048ad18>] call_usermodehelper_exec+0x138/0x1c0
> [ 2.019177] [<000000000052eb40>] __request_module+0x160/0x2e0
> [ 2.019316] [<00000000009ba6dc>] crypto_alg_mod_lookup+0x17c/0x280
> [ 2.019466] [<00000000009ba990>] crypto_alloc_tfm_node+0x30/0x100
> [ 2.019614] [<00000000009dcc5c>]
> public_key_verify_signature+0xbc/0x260
> [ 2.019772] [<00000000009ded8c>] x509_check_for_self_signed+0xac/0x280
> [ 2.019928] [<00000000009dddec>] x509_cert_parse+0x14c/0x220
> [ 2.020065] [<00000000009dea08>] x509_key_preparse+0x8/0x1e0
>
> The problem here is
>
> typedef struct {
> spinlock_t lock; <--
> unsigned long sparc64_ctx_val;
> unsigned long hugetlb_pte_count;
> unsigned long thp_pte_count;
> struct tsb_config tsb_block[MM_NUM_TSBS];
> struct hv_tsb_descr tsb_descr[MM_NUM_TSBS];
> void *vdso;
> bool adi;
> tag_storage_desc_t *tag_store;
> spinlock_t tag_lock;
> } mm_context_t;
>
> Replacing that with a raw spinlock just triggers the next one.
>
> [ 2.035384] =============================
> [ 2.035490] [ BUG: Invalid wait context ]
> [ 2.035660] 6.12.0+ #3 Not tainted
> [ 2.035802] -----------------------------
> [ 2.035906] kworker/u4:3/48 is trying to lock:
> [ 2.036036] 0000000001b6a790 (ctx_alloc_lock){....}-{3:3}, at:
> get_new_mmu_context+0x14/0x280
> [ 2.036558] other info that might help us debug this:
> [ 2.036697] context-{5:5}
> [ 2.036784] 4 locks held by kworker/u4:3/48:
> [ 2.036906] #0: fffff80004838a70
> (&sig->cred_guard_mutex){+.+.}-{4:4}, at: bprm_execve+0xc/0x8e0
> [ 2.037169] #1: fffff80004838b08
> (&sig->exec_update_lock){+.+.}-{4:4}, at: begin_new_exec+0x344/0xbe0
> [ 2.037411] #2: fffff800047fc940 (&p->alloc_lock){+.+.}-{3:3}, at:
> begin_new_exec+0x3a0/0xbe0
> [ 2.037639] #3: fffff80004848610 (&mm->context.lock){....}-{2:2},
> at: begin_new_exec+0x41c/0xbe0
>
> Fixing that finally gives me a clean run. Nevertheless, that makes me
> wonder:
> Should I just disable CONFIG_PROVE_RAW_LOCK_NESTING for sparc runtime
> tests ?
If no one is tryng to ever enable PREEMPT_RT on SPARC, I suppose you
could disable CONFIG_PROVE_RAW_LOCK_NESTING to avoid the trouble.
Cheers,
Longman
next prev parent reply other threads:[~2024-11-25 19:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 15:45 [PATCH 0/1] lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING Sebastian Andrzej Siewior
2024-10-09 15:45 ` [PATCH 1/1] " Sebastian Andrzej Siewior
2024-10-09 16:50 ` Waiman Long
2024-10-09 22:47 ` Boqun Feng
2024-10-22 21:53 ` [tip: locking/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-11-23 16:27 ` [PATCH 1/1] " Guenter Roeck
2024-11-25 8:53 ` [PATCH] sparc/pci: Make pci_poke_lock a raw_spinlock_t Sebastian Andrzej Siewior
2024-11-25 17:01 ` Guenter Roeck
2024-11-25 17:43 ` Sebastian Andrzej Siewior
2024-11-25 17:59 ` Guenter Roeck
2024-11-25 18:12 ` Sebastian Andrzej Siewior
2024-11-25 19:23 ` Guenter Roeck
2024-11-25 19:33 ` Waiman Long [this message]
2024-11-25 20:06 ` Guenter Roeck
2024-11-25 20:23 ` Guenter Roeck
2024-11-25 20:54 ` Waiman Long
2024-11-25 21:25 ` Guenter Roeck
2024-11-25 21:29 ` Waiman Long
2024-11-25 21:54 ` Guenter Roeck
2024-11-25 22:33 ` Waiman Long
2024-11-26 11:20 ` Sebastian Andrzej Siewior
2024-11-26 16:59 ` Waiman Long
2024-11-27 15:39 ` Andreas Larsson
2024-11-27 16:02 ` Guenter Roeck
2024-11-27 16:53 ` Sebastian Andrzej Siewior
2024-11-27 17:44 ` Guenter Roeck
2024-11-27 23:47 ` Waiman Long
2024-11-28 0:08 ` Guenter Roeck
2024-11-28 0:31 ` Waiman Long
2024-11-28 1:17 ` Guenter Roeck
2024-11-28 1:55 ` Waiman Long
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=5d269249-afd1-44f5-8faf-9ac11d9a3beb@redhat.com \
--to=llong@redhat.com \
--cc=andreas@gaisler.com \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.