From: Waiman Long <llong@redhat.com>
To: paulmck@kernel.org, peterz@infradead.org, mingo@redhat.com,
will@kernel.org, boqun.feng@gmail.com
Cc: linux-kernel@vger.kernel.org, richard@nod.at
Subject: Re: Confusing lockdep splat
Date: Fri, 24 Sep 2021 17:41:17 -0400 [thread overview]
Message-ID: <d8cb4445-cb01-4405-8800-a3eefa253af1@redhat.com> (raw)
In-Reply-To: <20210924210247.GA3877322@paulmck-ThinkPad-P17-Gen-1>
On 9/24/21 5:02 PM, Paul E. McKenney wrote:
> Hello!
>
> I got the lockdep splat below from an SRCU-T rcutorture run, which uses
> a !SMP !PREEMPT kernel. This is a random event, and about half the time
> it happens within an hour or two. My reproducer (on current -rcu "dev"
> branch for a 16-CPU system) is:
>
> tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 16 --configs "16*SRCU-T" --duration 7200
>
> My points of confusion are as follows:
>
> 1. The locks involved in this deadlock cycle are irq-disabled
> raw spinlocks. The claimed deadlock cycle uses two CPUs.
> There is only one CPU. There is no possibility of preemption
> or interrupts. So how can this deadlock actually happen?
>
> 2. If there was more than one CPU, then yes, there would be
> a deadlock. The PI lock is acquired by the wakeup code after
> acquiring the workqueue lock, and rcutorture tests the new ability
> of the scheduler to hold the PI lock across rcu_read_unlock(),
> and while it is at it, across the rest of the unlock primitives.
>
> But if there was more than one CPU, Tree SRCU would be used
> instead of Tiny SRCU, and there would be no wakeup invoked from
> srcu_read_unlock().
>
> Given only one CPU, there is no way to complete the deadlock
> cycle.
>
> For now, I am working around this by preventing rcutorture from holding
> the PI lock across Tiny srcu_read_unlock().
>
> Am I missing something subtle here?
I would say that the lockdep code just doesn't have enough intelligence
to identify that deadlock is not possible in this special case. There
are certainly false positives, and it can be hard to get rid of them.
Cheers,
Longman
next prev parent reply other threads:[~2021-09-24 21:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 21:02 Confusing lockdep splat Paul E. McKenney
2021-09-24 21:41 ` Waiman Long [this message]
2021-09-24 22:43 ` Paul E. McKenney
2021-09-25 0:30 ` Waiman Long
2021-09-25 12:55 ` Paul E. McKenney
2021-09-25 2:38 ` Boqun Feng
2021-09-25 12:50 ` Paul E. McKenney
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=d8cb4445-cb01-4405-8800-a3eefa253af1@redhat.com \
--to=llong@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=richard@nod.at \
--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.