mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Nikita V. Youshchenko" <yoush@cs.msu.su>
Cc: Sujit K M <sjt.kar@gmail.com>,
	linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
Date: Thu, 20 May 2010 12:52:45 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1005201225170.3368@localhost.localdomain> (raw)
In-Reply-To: <201005201423.09075@zigzag.lvk.cs.msu.su>

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@linutronix.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@linutronix.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();
 }



  reply	other threads:[~2010-05-20 10:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 13:13 Xianghua Xiao
2010-05-18 19:28 ` Xianghua Xiao
2010-05-18 19:47   ` Thomas Gleixner
2010-05-18 20:49     ` Xianghua Xiao
2010-05-20  8:33     ` Nikita V. Youshchenko
2010-05-20  9:25       ` Sujit K M
2010-05-20  9:32         ` Sujit K M
2010-05-20  9:47           ` Thomas Gleixner
2010-05-20 10:23             ` Nikita V. Youshchenko
2010-05-20 10:52               ` Thomas Gleixner [this message]
2010-05-20 11:12                 ` Nikita V. Youshchenko
2010-05-20 11:23                   ` Thomas Gleixner
2010-05-20 11:40                     ` Nikita V. Youshchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1005201225170.3368@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=sjt.kar@gmail.com \
    --cc=yoush@cs.msu.su \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome