[lkml]   [2013]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
On Mon, 12 Aug 2013 15:53:10 +0200
Peter Zijlstra <> wrote:

> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> > Hi, Steven
> >
> > I was considering rtmutex's lock->wait_lock is a scheduler lock,
> > But it is not, and it is just a spinlock of process context.
> > I hope you change it to a spinlock of irq context.
> rwmutex::wait_lock is irq-safe; it had better be because its taken under
> task_struct::pi_lock.

It is? I thought it was the other way around. That is, pi_lock is taken
under wait_lock.

task_blocks_on_rt_mutex() is called with wait_lock held. The first
thing it does is to grab the pi_lock.

The wait_lock is the mutex internal lock. Currently, no interrupt
context should take that lock, or should there be an interrupt lock
held when it is taken. The lock should be taken in the same contexts
that a mutex can be taken in.

By making it a irq-safe lock, we need to disable interrupts every time
it is taken, which means the entire pi-chain walk in
rt_mutex_adjust_prio_chain() will pretty much be with interrupts
disabled. I really would like to avoid making wait_lock irq-safe if we
can avoid it. I'm sure it will have a large impact to the -rt kernel if
we convert it.

-- Steve

 \ /
  Last update: 2013-08-12 16:21    [W:0.245 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site