From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Juerg Haefliger <juergh@gmail.com>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <williams@redhat.com>
Subject: Re: [ANNOUNCE] 3.14.23-rt20
Date: Thu, 6 Nov 2014 00:11:32 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.11.1411052357110.24960@nanos> (raw)
In-Reply-To: <20141105174822.491e1eff@gandalf.local.home>
On Wed, 5 Nov 2014, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 23:29:32 +0100 (CET)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > > > When we allow multiple readers, this will be allowed. But even in
> > > > mainline, if a writer were to come in and block between those two
> > > > down_read_trylocks(), the second trylock would fail.
> > > >
> > > > PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> > > > be held by a single reader.
> > >
> > > Errm. The reader holds the sem already. So that's a recursive read
> > > lock which should always succeed. And rt_read_trylock() has that
> > > implemented.
> >
> > Bah. That's the rwlock path. Untested patch below should fix the issue.
>
> This is basically a revert of my patch that removed rwsems as being
> recursive, because they are not recursive in mainline.
Well, they are. Just not in the presence of a writer.
Which is silly, but due to the fact that we do not track the readers
unavoidable. If the reader holds the sem already there is no real
reason why it should not succeed with the recursive lock.
If anything relies on that behaviour then we have a way bigger
problem at some other place.
> If you have the following:
>
> down_read(&A);
>
> down_write(&A);
>
> down_read(&A);
>
> in mainline, you will have a deadlock. With this change, it will not
> deadlock on -rt.
And that's fine on RT in the face of a single reader.
> This is probably why that cpu governor code uses down_read_trylock()
> otherwise, it would have suffered from possible deadlock scenarios.
Right.
> But, for a quick solution, just use this patch. I'll start working on
> the multi rwsem readers again, and then I'll have to revert this to do
> that. But when we have multi readers again, we wont need to have this
> hack.
And how exactly are multi reader rwsem solving that problem?
Not at all. You still need to track recursion of an already 'owning'
reader unless you want to add it twice on the 'owner' list.
Thanks,
tglx
next prev parent reply other threads:[~2014-11-05 23:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 21:03 Steven Rostedt
2014-11-02 7:30 ` Mike Galbraith
[not found] ` <CADLDEKvFvw7Aa98tVtM3z5JV8oocKqAdV4PqOMoZH2mXZ6x2jg@mail.gmail.com>
2014-11-05 14:04 ` Juerg Haefliger
2014-11-05 14:27 ` Steven Rostedt
2014-11-05 14:43 ` Juerg Haefliger
2014-11-05 15:00 ` Steven Rostedt
2014-11-05 15:35 ` Harry van Haaren
2014-11-05 15:44 ` Mike Galbraith
2014-11-05 16:07 ` Thomas Gleixner
2014-11-05 16:07 ` Thomas Gleixner
2014-11-05 22:29 ` Thomas Gleixner
2014-11-05 22:48 ` Steven Rostedt
2014-11-05 23:11 ` Thomas Gleixner [this message]
[not found] ` <1414910967.5380.81.camel@marge.simpson.net>
2014-11-02 7:30 ` 3.14.23-rt20 - sched/numa: Fix task_numa_free() lockdep splat Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - wwmutex: fix __ww_mutex_lock_interruptible lockdep annotation Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - mm,memcg: make refill_stock()/consume_stock() use get_cpu_light() Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - fs,btrfs: fix rt deadlock on extent_buffer->lock Mike Galbraith
2015-02-17 11:56 ` Sebastian Andrzej Siewior
2015-02-17 12:23 ` Mike Galbraith
2015-02-18 10:47 ` Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - aio: fix rcu garbage collection might_sleep() splat Mike Galbraith
2015-02-17 12:53 ` Sebastian Andrzej Siewior
2015-02-17 14:01 ` Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - x86, UV: raw_spinlock conversion Mike Galbraith
2015-02-17 13:02 ` Sebastian Andrzej Siewior
2015-02-17 14:11 ` Mike Galbraith
2014-11-02 7:31 ` 3.14.23-rt20 - softirq: resurrect softirq threads Mike Galbraith
2015-02-17 13:05 ` Sebastian Andrzej Siewior
2015-02-17 14:00 ` Mike Galbraith
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=alpine.DEB.2.11.1411052357110.24960@nanos \
--to=tglx@linutronix.de \
--cc=C.Emde@osadl.org \
--cc=bigeasy@linutronix.de \
--cc=jkacur@redhat.com \
--cc=juergh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=umgwanakikbuti@gmail.com \
--cc=williams@redhat.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 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®