Re: [PATCH] printk deadlocks if called with runqueue lock held

[Steven Rostedt]

On Fri, 18 Jan 2008, Jan Kiszka wrote:

> Steven Rostedt wrote:
> ....
> > @@ -978,7 +980,13 @@ void release_console_sem(void)
> >  	console_locked = 0;
> >  	up(&console_sem);
>
> Hmm, just looking at this fragment: Doesn't up() include the risk of
> running onto the runqueue lock as well?

Very little risk (if any). If printk fails to get the console_sem it
doesn't block. So there would be no waiters on the semaphore, and thus
try_to_wake_up would not be called. The only place I see the down
actually being called is in suspend code, and even then, we would need to
lock the rq of the task that is trying to grab the console_sem and the
deadlock would only occur if that was on the same CPU. And honestly, I'm
not sure that's even possible.

-- Steve


>
> >  	spin_unlock_irqrestore(&logbuf_lock, flags);
> > -	if (wake_klogd)
> > +	/*
> > +	 * If we try to wake up klogd while printing with the runqueue lock
> > +	 * held, this will deadlock. We don't have access to the runqueue
> > +	 * lock from here, but just checking for interrupts disabled
> > +	 * should be enough.
> > +	 */
> > +	if (!irqs_disabled() && wake_klogd)
> >  		wake_up_klogd();
> >  }
> >  EXPORT_SYMBOL(release_console_sem);
>
> Jan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/