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
| ||
|
Date: Wed, 23 Jan 2008 12:27:12 -0500 (EST) From: Steven Rostedt <rostedt@...dmis.org> To: Daniel Walker <dwalker@...sta.com> cc: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Christoph Hellwig <hch@...radead.org>, Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>, Gregory Haskins <ghaskins@...ell.com>, Arnaldo Carvalho de Melo <acme@...stprotocols.net>, Thomas Gleixner <tglx@...utronix.de>, Tim Bird <tim.bird@...sony.com>, Sam Ravnborg <sam@...nborg.org>, "Frank Ch. Eigler" <fche@...hat.com>, Jan Kiszka <jan.kiszka@...mens.com>, John Stultz <johnstul@...ibm.com>, Arjan van de Ven <arjan@...radead.org>, Steven Rostedt <srostedt@...hat.com> Subject: Re: [PATCH 01/20 -v5] printk - dont wakeup klogd with interrupts disabled On Wed, 23 Jan 2008, Daniel Walker wrote: > > On Wed, 2008-01-23 at 11:02 -0500, Steven Rostedt wrote: > > > + if (!irqs_disabled() && wake_klogd) > > wake_up_klogd(); > > This causes a regression .. When printk is called during an OOPS in > kernels without this change then the OOPS will get logged, since the > logging process (klogd) is woken to handle the messages.. If you apply > this change klogd doesn't wakeup, and hence doesn't log the oops.. So if > you remove the wakeup here you have to add it someplace else to maintain > the logging .. > > (I'm not theorizing here, I have defects logged against this specific > piece of code..) It wont get woken up anyway. Did you look at wake_up_klogd? void wake_up_klogd(void) { if (!oops_in_progress && waitqueue_active(&log_wait)) wake_up_interruptible(&log_wait); } So if oops_in_progress is set, then it still wont get woken. Perhaps it got woken some other way? Or is oops_in_progress not set in these oops? One other solution is to make the runqueue locks visible externally. Like: in sched.c: int runqueue_is_locked(void) { int cpu = get_cpu(); struct rq *rq = cpu_rq(cpu); int ret; ret = spin_is_locked(&rq->lock); put_cpu(); return ret; } And in printk we could do: if (wake_klogd && !runqueue_is_locked()) wake_up_klogd(); This probably is the cleanest solution since it simply prevents the deadlock from occurring. -- 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/
Powered by blists - more mailing lists