From: Peter Zijlstra <peterz@infradead.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andrea Parri <andrea.parri@amarulasolutions.com>,
zhe.he@windriver.com, catalin.marinas@arm.com,
tglx@linutronix.de, rostedt@goodmis.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
boqun.feng@gmail.com
Subject: Re: [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT
Date: Mon, 26 Nov 2018 09:40:42 +0100 [thread overview]
Message-ID: <20181126084042.GK2113@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181123110611.s2gmd237j7docrxt@linutronix.de>
On Fri, Nov 23, 2018 at 12:06:11PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-11-23 12:02:55 [+0100], Andrea Parri wrote:
> > > is this an RT-only problem? Because mainline should not allow read->read
> > > locking or read->write locking for reader-writer locks. If this only
> > > happens on v4.18 and not on v4.19 then something must have fixed it.
> >
> > Probably misunderstanding, but I'd say that read->read locking is "the
> > norm"...?
> >
> > If you don't use qrwlock, readers are also "recursive", in part.,
> >
> > P0 P1
> > read_lock(l)
> > write_lock(l)
> > read_lock(l)
> >
> > won't block P0 on the second read_lock(). (qrwlock somehow complicate
> > the analysis; IIUC, they are recursive if and only if in_interrupt().).
>
> ehm, peterz, is that true? My memory on that is that all readers will
> block if there is a writer pending.
Since qrwlock is the more strict, all users should use its semantics.
Just like we cannot 'rely' on the unfairness of some lock
implementations.
next prev parent reply other threads:[~2018-11-26 8:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 9:04 [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT zhe.he
2018-11-22 9:04 ` zhe.he
2018-11-22 10:16 ` Sebastian Andrzej Siewior
2018-11-23 9:53 ` Sebastian Andrzej Siewior
2018-11-23 11:02 ` Andrea Parri
2018-11-23 11:06 ` Sebastian Andrzej Siewior
2018-11-23 11:31 ` Catalin Marinas
2018-11-23 15:51 ` Steven Rostedt
2018-11-26 8:40 ` Peter Zijlstra [this message]
2018-11-24 14:26 ` He Zhe
2018-11-24 14:26 ` He Zhe
2018-11-24 14:26 ` He Zhe
2018-11-30 18:19 ` Sebastian Andrzej Siewior
2018-12-05 13:53 ` He Zhe
2018-12-05 13:53 ` He Zhe
2018-12-05 19:14 ` Sebastian Andrzej Siewior
2018-12-18 10:51 ` He Zhe
2018-12-18 10:51 ` He Zhe
2018-12-18 15:07 ` Catalin Marinas
2018-12-19 15:30 ` Sebastian Andrzej Siewior
2018-12-20 1:46 ` He Zhe
2018-12-20 1:46 ` He Zhe
2018-12-18 15:12 ` Catalin Marinas
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=20181126084042.GK2113@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrea.parri@amarulasolutions.com \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=zhe.he@windriver.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 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.