Re: [PATCH 01/23 -v6] printk - dont wakeup klogd with interruptsdisabled

[Steven Rostedt]

On Sat, 26 Jan 2008, Peter Zijlstra wrote:
> >
> > I guess you are going to kill me... but
> >
> > CPU0					CPU1
> > if (!runqueue_is_locked()) {
> > 					locks runqueue
> > 	wake_up_klogd
> >
> > ....and we are dead. What is needed here is
> > "wake_up_klogd_if_you_can()" or something, that does trylock (atomic).
> >
> > ....but even this version is better than status quo, I'd say.
>
> Well, if cpu1 holds the lock, and cpu0 wants it, there should only be
> contention, I'm not seeing how this would deadlock.
>
> The deadlock problem was when cpu0 was already holding the rq->lock and
> wants to take it again.

Correct. The only race that this patch has is that there's a slight chance
you wont wake up the klogd when you could.

  CPU0 						CPU1

					locks_runqueue(cpu0)

  if (!runqueue_is_locked())
     [fails and klogd not woken]


But this is rare and pretty harmless. But it can be trivally fixed and
should be. But I'll rename the API to

   current_has_runqueue_lock()

This way we know exactly why it returns what it returns.

-- Steve

--
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/