All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH RT 1/2] rwsem-rt: Do not allow readers to nest
Date: Wed, 25 Feb 2015 13:15:57 +0100	[thread overview]
Message-ID: <54EDBCFD.5030307@linutronix.de> (raw)
In-Reply-To: <20150218151352.2968cf06@grimm.local.home>

On 02/18/2015 09:13 PM, Steven Rostedt wrote:

>> Here the same thing but without cmpxchg(). _If_ after an increment the
>> value is negative then we take slowpath. Otherwise we have the lock.
> 
> OK, so I need to make it so it can nest with trylock. I have to look at
> the patch again because it has been a while.

I have reverted the patch and can confirm that cpufreq works again.

I did some testing on vanilla and -RT:
- down_read(l) + down_read(l)
  this triggers a lockdep warning about a possible deadlock the lock is
  obtained.

- down_read(l) + down_read_trylock()
  this passes without a warning.

So I think we good now.

> An RW sem must not do two down_read()s on the same lock (it's fine for
> a trylock if it has a fail safe for it). The reason is, the second
> down_read() will block if there's a writer waiting. Thus you are
> guaranteed a deadlock if you have the lock for read, a write comes in
> and waits, and you grab the RW sem again, because it will block, and
> the writer is waiting for the reader to release. Thus you have a
> deadlock.

I fully understand. However nesting is allowed according to the code in
vanilla and now again in -RT. Lockdep complains properly so we should
catch people doing it wrong in both trees.

> I'll have to revisit this. I also need to revisit the multi readers
> (although Thomas hates it, but he even admitted there's a better way to
> do it. Now only if I could remember what that was ;-)

Okay. For now I keep the revert since it looks sane and simple.

> 
> Thanks,
> 
> -- Steve

Sebastian

  parent reply	other threads:[~2015-02-25 12:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09  2:47 [PATCH RT 0/2] rwsem-rt: Make rwsem rt closer to mainline Steven Rostedt
2014-04-09  2:47 ` [PATCH RT 1/2] rwsem-rt: Do not allow readers to nest Steven Rostedt
2014-04-09  2:47   ` Steven Rostedt
2014-05-02  9:04   ` Sebastian Andrzej Siewior
2015-02-18 19:57   ` Sebastian Andrzej Siewior
2015-02-18 20:13     ` Steven Rostedt
2015-02-20  5:07       ` Jason Low
2015-02-25 12:15       ` Sebastian Andrzej Siewior [this message]
2014-04-09  2:47 ` [PATCH RT 2/2] rtmutex: Remove duplicate rt_mutex_init() Steven Rostedt
2014-04-09  2:47   ` Steven Rostedt
2014-05-02  9:08   ` Sebastian Andrzej Siewior
2014-05-02 13:12     ` Steven Rostedt
2014-05-02 13:21       ` Sebastian Andrzej Siewior

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=54EDBCFD.5030307@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=C.Emde@osadl.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.