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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jan 2008 20:57:51 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	adobriyan@...nvz.org, dev@...ru
Subject: Re: [PATCH] printk deadlocks if called with runqueue lock held


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 modifications
in try_to_wakeup, so seeing that in the backtrace, I thought I was the one
screwing up. But I was still certain that it was my code locking up.


> >
> > Calling printk with interrupts disabled should only be done for
> > emergencies and debugging anyway.
> >

> > +	 * 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);
>
> this looks fairly foul.  Might cause problems if one CPU is stuck with
> interrupts off spewing printks?

Well, we have more than one problem if that is happening.

>
> Couldn't you maintain a sched-hackers-only printk patch which adds a
> sched_printk() which avoids the wakeup or something like that?
>

Actually, the code that did trigger it was part of the latency_tracer
code doing the wakeup latency timings. Theres a printk that happens when
we trigger the max latency, and it prints from the scheduler.

So this was perfect to lock up every time.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/