mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Marcin Slusarz <marcin.slusarz@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] printk vs rq->lock and xtime lock
Date: Mon, 24 Mar 2008 11:16:43 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.00.0803241108190.17905@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0803241021350.17905@woody.linux-foundation.org>



On Mon, 24 Mar 2008, Linus Torvalds wrote:
> 
> Right now, however, I think that for 2.6.25 I'll just remove the printk. 

So I just committed that patch, but I was also looking at just making 
'printk()' itself more robust against this kind of thing.

Quite frankly, the printk() console semaphore etc handling is very 
confusing, and it has obviously evolved over time. Here's a suggested 
cleanup patch that doesn't actually *fix* anything, but it makes the 
resulting code flow a heck of a lot more readable.

In particular, it would now easily and readably allow us to add other 
rules inside the new "can_use_console()" that disable the console flushing 
if (for example) the request queue lock is held, or xlock is held for 
writing.

[ The patch adds more lines than it removes, but that is largely due to 
  the comments and the fact that it moves some of the code into new helper 
  functions, which invariably adds a few lines for the function definition 
  etc.

  There are actually fewer lines of actual code, because it ends up using
  the already-existing "try_acquire_console_sem()", and it avoids one ugly 
  special case, and removes some trivial code duplication about releasing 
  the logbuf_lock by reorganizing things a bit ]

Comments? 

			Linus
---
 kernel/printk.c |   83 +++++++++++++++++++++++++++++++-----------------------
 1 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/kernel/printk.c b/kernel/printk.c
index 9adc2a4..c46a20a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -616,6 +616,40 @@ asmlinkage int printk(const char *fmt, ...)
 /* cpu currently holding logbuf_lock */
 static volatile unsigned int printk_cpu = UINT_MAX;
 
+/*
+ * Can we actually use the console at this time on this cpu?
+ *
+ * Console drivers may assume that per-cpu resources have
+ * been allocated. So unless they're explicitly marked as
+ * being able to cope (CON_ANYTIME) don't call them until
+ * this CPU is officially up.
+ */
+static inline int can_use_console(unsigned int cpu)
+{
+	return cpu_online(cpu) || have_callable_console();
+}
+
+/*
+ * Try to get console ownership to actually show the kernel
+ * messages from a 'printk'. Return true (and with the
+ * console_semaphore held, and 'console_locked' set) if it
+ * is successful, false otherwise.
+ *
+ * This gets called with the 'logbuf_lock' spinlock held and
+ * interrupts disabled. It should return with 'lockbuf_lock'
+ * released but interrupts still disabled.
+ */
+static int acquire_console_semaphore_for_printk(unsigned int cpu)
+{
+	int retval = 0;
+
+	if (can_use_console(cpu))
+		retval = !try_acquire_console_sem();
+	printk_cpu = UINT_MAX;
+	spin_unlock(&logbuf_lock);
+	return retval;
+}
+
 const char printk_recursion_bug_msg [] =
 			KERN_CRIT "BUG: recent printk recursion!\n";
 static int printk_recursion_bug;
@@ -725,43 +759,22 @@ asmlinkage int vprintk(const char *fmt, va_list args)
 			log_level_unknown = 1;
 	}
 
-	if (!down_trylock(&console_sem)) {
-		/*
-		 * We own the drivers.  We can drop the spinlock and
-		 * let release_console_sem() print the text, maybe ...
-		 */
-		console_locked = 1;
-		printk_cpu = UINT_MAX;
-		spin_unlock(&logbuf_lock);
+	/*
+	 * Try to acquire and then immediately release the
+	 * console semaphore. The release will do all the
+	 * actual magic (print out buffers, wake up klogd,
+	 * etc). 
+	 *
+	 * The acquire_console_semaphore_for_printk() function
+	 * will release 'logbuf_lock' regardless of whether it
+	 * actually gets the semaphore or not.
+	 */
+	if (acquire_console_semaphore_for_printk(this_cpu))
+		release_console_sem();
 
-		/*
-		 * Console drivers may assume that per-cpu resources have
-		 * been allocated. So unless they're explicitly marked as
-		 * being able to cope (CON_ANYTIME) don't call them until
-		 * this CPU is officially up.
-		 */
-		if (cpu_online(smp_processor_id()) || have_callable_console()) {
-			console_may_schedule = 0;
-			release_console_sem();
-		} else {
-			/* Release by hand to avoid flushing the buffer. */
-			console_locked = 0;
-			up(&console_sem);
-		}
-		lockdep_on();
-		raw_local_irq_restore(flags);
-	} else {
-		/*
-		 * Someone else owns the drivers.  We drop the spinlock, which
-		 * allows the semaphore holder to proceed and to call the
-		 * console drivers with the output which we just produced.
-		 */
-		printk_cpu = UINT_MAX;
-		spin_unlock(&logbuf_lock);
-		lockdep_on();
+	lockdep_on();
 out_restore_irqs:
-		raw_local_irq_restore(flags);
-	}
+	raw_local_irq_restore(flags);
 
 	preempt_enable();
 	return printed_len;

      parent reply	other threads:[~2008-03-24 18:17 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 12:24 Peter Zijlstra
2008-03-24 12:24 ` [PATCH 1/2] printk_nowakeup() Peter Zijlstra
2008-03-24 12:24 ` [PATCH 2/2] time: xtime lock vs printk Peter Zijlstra
2008-03-24 14:21   ` Daniel Walker
2008-03-24 14:31 ` [PATCH 0/2] printk vs rq->lock and xtime lock Marcin Slusarz
2008-03-24 17:58 ` Linus Torvalds
2008-03-24 18:15   ` Peter Zijlstra
2008-03-24 18:57     ` Andrew Morton
2008-08-08 13:30       ` Peter Zijlstra
2008-08-08 13:46         ` Peter Zijlstra
2008-08-08 16:41         ` Linus Torvalds
2008-08-08 17:10           ` Peter Zijlstra
2008-08-08 17:25             ` Linus Torvalds
2008-08-08 17:40               ` Peter Zijlstra
2008-08-08 17:48                 ` Linus Torvalds
2008-08-08 18:14                   ` [PATCH] printk: robustify printk Peter Zijlstra
2008-08-08 18:30                     ` Linus Torvalds
2008-08-08 18:33                       ` Peter Zijlstra
2008-08-08 19:14                     ` Andrew Morton
2008-08-08 19:21                       ` Peter Zijlstra
2008-08-08 19:37                         ` Andrew Morton
2008-08-08 19:49                           ` Peter Zijlstra
2008-08-08 20:32                           ` Paul E. McKenney
2008-08-08 20:37                             ` Peter Zijlstra
2008-08-08 20:46                               ` Andrew Morton
2008-08-08 20:57                                 ` Linus Torvalds
2008-08-08 21:13                                   ` Andrew Morton
2008-08-08 20:50                               ` Steven Rostedt
2008-08-08 19:47                         ` Peter Zijlstra
2008-08-11 10:45                           ` Ingo Molnar
2008-08-11 11:03                             ` Andi Kleen
2008-08-11 11:22                               ` Peter Zijlstra
2008-08-11 11:42                                 ` Andi Kleen
2008-08-11 14:15                                   ` Valdis.Kletnieks
2008-08-11 14:29                                     ` Andi Kleen
2008-08-11 14:55                                       ` Steven Rostedt
2008-08-11 12:02                                 ` Ingo Molnar
2008-08-11 12:14                                   ` Andi Kleen
2008-08-11 11:04                             ` Peter Zijlstra
2008-08-11 11:51                               ` Ingo Molnar
2008-08-11 12:36                                 ` Ingo Molnar
2008-08-20 12:40                                 ` Jiri Kosina
2008-08-20 12:43                                   ` Peter Zijlstra
2008-08-20 13:40                                     ` Ingo Molnar
2008-08-11 16:09                               ` Paul E. McKenney
2008-08-11 13:22                             ` Paul E. McKenney
2008-08-08 20:30                       ` Paul E. McKenney
2008-08-08 20:20                     ` Paul E. McKenney
2008-08-08 21:35                     ` Andi Kleen
2008-08-08 23:02                     ` David Miller
2008-08-09  0:18                       ` Paul E. McKenney
2008-08-08 17:52                 ` [PATCH 0/2] printk vs rq->lock and xtime lock Steven Rostedt
2008-03-24 18:16   ` Linus Torvalds [this message]

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.1.00.0803241108190.17905@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®