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

2008-01-24 Thread Pavel Machek
On Wed 2008-01-23 13:36:12, Steven Rostedt wrote: > > > On Wed, 23 Jan 2008, Pavel Machek wrote: > > > > Could try_to_wakeup use trylock, and only avoid wakeup if lock is > > already held? > > Pavel > > I could imagine a lot of missed wakeups

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

2008-01-24 Thread Pavel Machek
On Wed 2008-01-23 13:36:12, Steven Rostedt wrote: On Wed, 23 Jan 2008, Pavel Machek wrote: Could try_to_wakeup use trylock, and only avoid wakeup if lock is already held? Pavel I could imagine a lot of missed wakeups caused by

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

2008-01-23 Thread Steven Rostedt
On Wed, 23 Jan 2008, Pavel Machek wrote: > > Could try_to_wakeup use trylock, and only avoid wakeup if lock is > already held? > Pavel I could imagine a lot of missed wakeups caused by that. -- Steve -- To unsubscribe from this list: send

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

2008-01-23 Thread Pavel Machek
Hi! > I thought that one could place a printk anywhere without worrying. > But it seems that it is not wise to place a printk where the runqueue > lock is held. > > I just spent two hours debugging why some of my code was locking up, > to find that the lockup was caused by some debugging

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

2008-01-23 Thread Pavel Machek
Hi! I thought that one could place a printk anywhere without worrying. But it seems that it is not wise to place a printk where the runqueue lock is held. I just spent two hours debugging why some of my code was locking up, to find that the lockup was caused by some debugging printk's that

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

2008-01-23 Thread Steven Rostedt
On Wed, 23 Jan 2008, Pavel Machek wrote: Could try_to_wakeup use trylock, and only avoid wakeup if lock is already held? Pavel I could imagine a lot of missed wakeups caused by that. -- Steve -- To unsubscribe from this list: send the

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

2008-01-18 Thread Linus Torvalds
On Fri, 18 Jan 2008, Jan Kiszka wrote: > Steven Rostedt wrote: > ... > > @@ -978,7 +980,13 @@ void release_console_sem(void) > > console_locked = 0; > > up(_sem); > > Hmm, just looking at this fragment: Doesn't up() include the risk of > running onto the runqueue lock as well? In

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

2008-01-18 Thread 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(_sem); > > Hmm, just looking at this fragment: Doesn't up() include the risk of > running onto the runqueue lock as well? Very

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

2008-01-18 Thread Jan Kiszka
Steven Rostedt wrote: ... > @@ -978,7 +980,13 @@ void release_console_sem(void) > console_locked = 0; > up(_sem); Hmm, just looking at this fragment: Doesn't up() include the risk of running onto the runqueue lock as well? > spin_unlock_irqrestore(_lock, flags); > - if

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

2008-01-18 Thread Steven Rostedt
On Fri, 18 Jan 2008, Jiri Kosina wrote: > > If this patch is going to be merged, you should perhaps adjust the comment > introduced by the above mentioned commit, so that it reflects the new > behavior. Thanks for pointing this out. Updated patch below: -- Steve = I thought that one

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

2008-01-18 Thread Jiri Kosina
On Thu, 17 Jan 2008, Steven Rostedt wrote: > Thinking that it was locking up on my code I went looking down the wrong > path. I finally found (after examining an NMI dump) that the lockup > happened because printk was trying to wakeup the klogd daemon, which > caused a deadlock when the

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

2008-01-18 Thread Steven Rostedt
On Fri, 18 Jan 2008, Jiri Kosina wrote: If this patch is going to be merged, you should perhaps adjust the comment introduced by the above mentioned commit, so that it reflects the new behavior. Thanks for pointing this out. Updated patch below: -- Steve = I thought that one could

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

2008-01-18 Thread Jiri Kosina
On Thu, 17 Jan 2008, Steven Rostedt wrote: Thinking that it was locking up on my code I went looking down the wrong path. I finally found (after examining an NMI dump) that the lockup happened because printk was trying to wakeup the klogd daemon, which caused a deadlock when the

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

2008-01-18 Thread 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

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

2008-01-18 Thread Jan Kiszka
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? spin_unlock_irqrestore(logbuf_lock, flags); -

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

2008-01-18 Thread Linus Torvalds
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? In theory

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

2008-01-17 Thread Steven Rostedt
On Thu, 17 Jan 2008, Andrew Morton wrote: > > A "well-known" problem which few know about ;) And now I feel less ignorant. > > Anyway you should be developing with all debug options enabled and that > includes NMI watchdog so there. hehe, I did have NMI on the whole time. It's that I also had

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

2008-01-17 Thread Steven Rostedt
On Thu, 17 Jan 2008, Linus Torvalds wrote: > IOW, I think this should be > > if (raw_irqs_disabled_flags(flags) && wake_klogd) > wake_up_klogd(); > > Of course, not all architectures seem to suport that thing (it's currently > only used by the CONFIG_TRACE_IRQFLAGS config

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

2008-01-17 Thread Linus Torvalds
On Thu, 17 Jan 2008, Steven Rostedt wrote: > > Calling printk with interrupts disabled should only be done for > emergencies and debugging anyway. Agreed, I think this is sane. > And with this patch, my code ran fine ;-) Patch looks fine, but I'm saddened: > + /* > + * If we try to

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

2008-01-17 Thread Andrew Morton
On Thu, 17 Jan 2008 20:04:27 -0500 (EST) Steven Rostedt <[EMAIL PROTECTED]> wrote: > > I thought that one could place a printk anywhere without worrying. > But it seems that it is not wise to place a printk where the runqueue > lock is held. > > I just spent two hours debugging why some of my

[PATCH] printk deadlocks if called with runqueue lock held

2008-01-17 Thread Steven Rostedt
I thought that one could place a printk anywhere without worrying. But it seems that it is not wise to place a printk where the runqueue lock is held. I just spent two hours debugging why some of my code was locking up, to find that the lockup was caused by some debugging printk's that I had in

[PATCH] printk deadlocks if called with runqueue lock held

2008-01-17 Thread Steven Rostedt
I thought that one could place a printk anywhere without worrying. But it seems that it is not wise to place a printk where the runqueue lock is held. I just spent two hours debugging why some of my code was locking up, to find that the lockup was caused by some debugging printk's that I had in

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

2008-01-17 Thread Andrew Morton
On Thu, 17 Jan 2008 20:04:27 -0500 (EST) Steven Rostedt [EMAIL PROTECTED] wrote: I thought that one could place a printk anywhere without worrying. But it seems that it is not wise to place a printk where the runqueue lock is held. I just spent two hours debugging why some of my code was

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

2008-01-17 Thread Linus Torvalds
On Thu, 17 Jan 2008, Steven Rostedt wrote: Calling printk with interrupts disabled should only be done for emergencies and debugging anyway. Agreed, I think this is sane. And with this patch, my code ran fine ;-) Patch looks fine, but I'm saddened: + /* + * If we try to wake

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

2008-01-17 Thread Steven Rostedt
On Thu, 17 Jan 2008, Linus Torvalds wrote: IOW, I think this should be if (raw_irqs_disabled_flags(flags) wake_klogd) wake_up_klogd(); Of course, not all architectures seem to suport that thing (it's currently only used by the CONFIG_TRACE_IRQFLAGS config option).

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

2008-01-17 Thread Steven Rostedt
On Thu, 17 Jan 2008, Andrew Morton wrote: A well-known problem which few know about ;) And now I feel less ignorant. Anyway you should be developing with all debug options enabled and that includes NMI watchdog so there. hehe, I did have NMI on the whole time. It's that I also had