linux-toradex.git/kernel/printk.c, branch v3.2-rc5

printk: avoid double lock acquire

2011-12-09T15:50:28+00:00

Commit 4f2a8d3cf5e ("printk: Fix console_sem vs logbuf_lock unlock race")
introduced another silly bug where we would want to acquire an already
held lock.  Avoid this.

Reported-by: Andrea Arcangeli 
Signed-off-by: Peter Zijlstra 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

printk: remove bounds checking for log_prefix

2011-11-01T00:30:53+00:00

Currently log_prefix is testing that the first character of the log level
and facility is less than '0' and greater than '9' (which is always
false).

Since the code being updated works because strtoul bombs out (endp isn't
updated) and 0 is returned anyway just remove the check and don't change
the behavior of the function.

Signed-off-by: William Douglas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

printk: fix bounds checking for log_prefix

2011-11-01T00:30:53+00:00

Currently log_prefix is testing that the first character of the log level
and facility is less than '0' and greater than '9' (which is always
false).  It should be testing to see if the character less than '0' or
greater than '9' instead.  This patch makes that change.

The code being changed worked because strtoul bombs out (endp isn't
updated) and 0 is returned anyway.

Signed-off-by: William Douglas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

printk: add console_suspend module parameter

2011-11-01T00:30:53+00:00

We are enabling some power features on medfield.  To test suspend-2-RAM
conveniently, we need turn on/off console_suspend_enabled frequently.

Add a module parameter, so users could change it by:
/sys/module/printk/parameters/console_suspend

Signed-off-by: Yanmin Zhang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

printk: add module parameter ignore_loglevel to control ignore_loglevel

2011-11-01T00:30:53+00:00

We are enabling some power features on medfield.  To test suspend-2-RAM
conveniently, we need turn on/off ignore_loglevel frequently without
rebooting.

Add a module parameter, so users can change it by:
/sys/module/printk/parameters/ignore_loglevel

Signed-off-by: Yanmin Zhang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

locking, printk: Annotate logbuf_lock as raw

2011-09-13T09:11:54+00:00

The logbuf_lock lock can be taken in atomic context and therefore
cannot be preempted on -rt - annotate it.

In mainline this change documents the low level nature of
the lock - otherwise there's no functional difference. Lockdep
and Sparse checking will work as usual.

Signed-off-by: Thomas Gleixner 
[ merged and fixed it ]
Signed-off-by: Ingo Molnar

kernel/printk: do not turn off bootconsole in printk_late_init() if keep_bootcon

2011-08-25T23:25:34+00:00

It seems that 7bf693951a8e ("console: allow to retain boot console via
boot option keep_bootcon") doesn't always achieve what it aims, as when
printk_late_init() runs it unconditionally turns off all boot consoles.
With this patch, I am able to see more messages on the boot console in
KVM guests than I can without, when keep_bootcon is specified.

I think it is appropriate for the relevant -stable trees.  However, it's
more of an annoyance than a serious bug (ideally you don't need to keep
the boot console around as console handover should be working -- I was
encountering a situation where the console handover wasn't working and
not having the boot console available meant I couldn't see why).

Signed-off-by: Nishanth Aravamudan 
Cc: David S. Miller 
Cc: Alan Cox 
Cc: Greg KH 
Acked-by: Fabio M. Di Nitto 
Cc: 		[2.6.39.x, 3.0.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cap_syslog: don't use WARN_ONCE for CAP_SYS_ADMIN deprecation warning

2011-08-10T01:22:22+00:00

syslog-ng versions before 3.3.0beta1 (2011-05-12) assume that
CAP_SYS_ADMIN is sufficient to access syslog, so ever since CAP_SYSLOG
was introduced (2010-11-25) they have triggered a warning.

Commit ee24aebffb75 ("cap_syslog: accept CAP_SYS_ADMIN for now")
improved matters a little by making syslog-ng work again, just keeping
the WARN_ONCE().  But still, this is a warning that writes a stack trace
we don't care about to syslog, sets a taint flag, and alarms sysadmins
when nothing worse has happened than use of an old userspace with a
recent kernel.

Convert the WARN_ONCE to a printk_once to avoid that while continuing to
give userspace developers a hint that this is an unwanted
backward-compatibility feature and won't be around forever.

Reported-by: Ralf Hildebrandt 
Reported-by: Niels 
Reported-by: Paweł Sikora 
Signed-off-by: Jonathan Nieder 
Liked-by: Gergely Nagy 
Acked-by: Serge Hallyn 
Acked-by: James Morris 
Signed-off-by: Linus Torvalds

printk: Fix console_sem vs logbuf_lock unlock race

2011-06-22T09:39:34+00:00

Fix up the fallout from commit 0b5e1c5255 ("printk: Release
console_sem after logbuf_lock").

The reason for unlocking the console_sem under the logbuf_lock
is that a concurrent printk() might fill up the buffer but fail
to acquire the console sem, resulting in a missed write to the
console until a subsequent console_sem acquire/release cycle.

Signed-off-by: Peter Zijlstra 
Cc: efault@gmx.de
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/1308734409.1022.14.camel@twins
Signed-off-by: Ingo Molnar

printk: Release console_sem after logbuf_lock

2011-06-07T10:50:02+00:00

Release console_sem after unlocking the logbuf_lock so that we don't
generate wakeups while holding logbuf_lock. This avoids some lock
inversion troubles once we remove the lockdep_off bits between
logbuf_lock and rq->lock (prints while holding rq->lock vs doing
wakeups while holding logbuf_lock).

There's of course still an actual deadlock where the printk()s under
rq->lock will issue a wakeup from the up() call, but lockdep won't
warn about that since semaphores are not tracked.

Signed-off-by: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/n/tip-j8swthl12u73h4znbvitljzd@git.kernel.org
Signed-off-by: Ingo Molnar