From: Boqun Feng <boqun.feng@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Gautham R Shenoy <ego@in.ibm.com>,
Byungchul Park <byungchul.park@lge.com>,
Boqun Feng <boqun.feng@gmail.com>
Subject: [RFC tip 0/5] lockdep: Support deadlock detection for recursive read locks
Date: Mon, 28 Aug 2017 22:56:52 +0800 [thread overview]
Message-ID: <20170828145657.11292-1-boqun.feng@gmail.com> (raw)
Hi Ingo and Peter,
As Peter pointed out:
https://marc.info/?l=linux-kernel&m=150349072023540
The lockdep current has a limit support for recursive read locks, the
deadlock case as follow could not be detected:
read_lock(A);
lock(B);
lock(B);
write_lock(A);
I got some inspiration from Gautham R Shenoy:
https://lwn.net/Articles/332801/
, and came up with this series.
The basic idea is:
* Add recursive read locks into the graph
* Classify dependencies into R->R, N->R, R->N, N->N, where R
stands for recursive read lock, N stands for other locks.
* Extend __bfs() to go through all kinds of dependencies and the
read/write status could be changed in the traverse(i.e. with
dependency N(A)->R(B) and N(B)->R(C), BFS could go from A to B
and then to C).
* But don't allow use a lock B as a transfer station if B only has
*->R dependencies to the previous lock and R->* dependencies to
the next lock. This is because if a BFS traverse has such a B as
a transfer station, the following exists:
CPU0 CPU1 CPU2 CPU3
lock(X);
lock(Y); lock(Y);
rlock(B); rlock(B);
lock(P); lock(P);
lock(Q);
The lock dependency breaks between CPU1 and CPU2, no deadlock.
In this way, we can reflect the real dependencies while taking recursive
read locks into considerations.
This is readlly an RFC, as I'm 100% sure I cover all the cases related
to read recursive locks, but I do add two sets of self testcases, and
they did pass ;-)
This series consists of 5 patches:
Patch #1 introduces a new test case to test chain cache behavior on the
recursive read deadlock detection.
Patch #2 introduces more complex cases for recursive read deadlock
detection.
Patch #3 does a little bit clean-up on the return value of __bfs() and
its friends.
Patch #4 adds recursive locks into dependency graph and extends BFS to
allow deadlock detection for recursive read locks.
Patch #5 fixes the problem that lock chains and chainkeys don't treat
read/write locks differently, which could miss the chance to detect a
deadlock because a lock chain cache hit.
I plan to write more tests and play about this in next weeks, just send
out for suggestions and comments.
Reviews and tests are welcome!
Regards,
Boqun
next reply other threads:[~2017-08-28 14:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 14:56 Boqun Feng [this message]
2017-08-28 14:56 ` [RFC tip 1/5] lockdep/selftest: Add a R-L/L-W test case specific to chain cache behavior Boqun Feng
2017-08-28 14:56 ` [RFC tip 2/5] lockdep/selftest: Add more recursive read related test cases Boqun Feng
2017-08-28 14:56 ` [RFC tip 3/5] lockdep: Demagic the return value of BFS Boqun Feng
2017-08-28 14:56 ` [RFC tip 4/5] lockdep: Support deadlock detection for recursive read locks in check_noncircular() Boqun Feng
2017-08-28 14:56 ` [RFC tip 5/5] lockdep: Take read/write status in consideration when generate chainkey Boqun Feng
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=20170828145657.11292-1-boqun.feng@gmail.com \
--to=boqun.feng@gmail.com \
--cc=byungchul.park@lge.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®