linux-kernel - Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console

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]

Message-ID: <alpine.LFD.2.00.1005201225170.3368@localhost.localdomain>
Date:	Thu, 20 May 2010 12:52:45 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Nikita V. Youshchenko" <yoush@...msu.su>
cc:	Sujit K M <sjt.kar@...il.com>, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after
 console_init

On Thu, 20 May 2010, Nikita V. Youshchenko wrote:

> > > >>> Well, obviously it's unsafe if you remove safety checks. And if
> > > >>> you care to look at the changelog of kernel/printk.c you'll find
> > > >>> out why.
> > > >>
> > > >> Hmm... did a quick look and could not find anything related there.
> > > >> Could you please give a pointer?
> >
> > Gah, yes. The changelog of the commit is not really helpful. Let me
> > explain:
> >
> > The console drivers might take locks, which are converted to "sleeping
> > locks" in preempt-rt. As a result we cannot call into those drivers
> > from atomic contexts. And that's what the checks in the printk code
> > prevent.
> 
> I've already understood that when looking at that code some weeks ago.
> 
> Still questions:
> 
> 1) why does that prevent klogd from working?

Patch below.
 
> 2) why does print not pass to non-CON_ATOMIC even if called from non-atomic 
> context?

That's a good question. We call release_console_mutex() always with
interrupts disabled from printk(), so that atomic check triggers. Have
to look deeper to figure out whether we can enable interupts there,
probably not, but with the klogd fix this should not matter.
 
> 3) I believe that 8250 serial driver is aware of preempt-rt.
> Could you please comment on my "2.6.33.2-rt13: RFC: fix serial console" 
> post to linux-rt-users list 
> (http://eeek.borgchat.net/lists/linux-rt-users/msg05569.html)

While that can work due to the trylock, it can introduce massive
latencies just in case some driver reports a status change or what
ever.

Thanks,

	tglx
----
Subject: printk: Fix missing klogd wakeup
From: Thomas Gleixner <tglx@...utronix.de>
Date: Thu, 20 May 2010 12:33:00 +0200

The RT check for !in_atomic() && !irqs_disabled()) to prevent the
klogd wakeup is actually bogus as wake_up_klogd() is just setting the
needs print flag which is then evaluated from printk_tick() which does
the actual wakeup.

Remove the double raw_spin_unlock_irqrestore(&logbuf_lock, flags)
while at it.

Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
 kernel/printk.c |   10 ----------
 1 file changed, 10 deletions(-)

Index: linux-2.6-tip/kernel/printk.c
===================================================================
--- linux-2.6-tip.orig/kernel/printk.c
+++ linux-2.6-tip/kernel/printk.c
@@ -1084,18 +1084,8 @@ void release_console_mutex(void)
 #endif
 	}
 	console_locked = 0;
-	raw_spin_unlock_irqrestore(&logbuf_lock, flags);
 	mutex_unlock(&console_mutex);
 
-	/*
-	 * On PREEMPT_RT kernels __wake_up may sleep, so wake syslogd
-	 * up only if we are in a preemptible section. We normally dont
-	 * printk from non-preemptible sections so this is for the emergency
-	 * case only.
-	 */
-#ifdef CONFIG_PREEMPT_RT
-	if (!in_atomic() && !irqs_disabled())
-#endif
 	if (wake_klogd)
 		wake_up_klogd();
 }


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