linux-stable.git/kernel/printk.c, branch v3.5.3

printk: Fix calculation of length used to discard records

2012-08-15T14:53:03+00:00

commit e3756477aec028427fec767957c0d4b6cfb87208 upstream.

While tracking down a weird buffer overflow issue in a program that
looked to be sane, I started double checking the length returned by
syslog(SYSLOG_ACTION_READ_ALL, ...) to make sure it wasn't overflowing
the buffer.

Sure enough, it was.  I saw this in strace:

  11339 syslog(SYSLOG_ACTION_READ_ALL, "<5>[244017.708129] REISERFS (dev"..., 8192) = 8279

It turns out that the loops that calculate how much space the entries
will take when they're copied don't include the newlines and prefixes
that will be included in the final output since prev flags is passed as
zero.

This patch properly accounts for it and fixes the overflow.

Signed-off-by: Jeff Mahoney 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kmsg - properly print over-long continuation lines

2012-08-09T15:22:54+00:00

commit 70498253186586e5dca7bc3ebd3415203b059fbc upstream.

Reserve PREFIX_MAX bytes in the LOG_LINE_MAX line when buffering a
continuation line, to be able to properly prefix the LOG_LINE_MAX
line with the syslog prefix and timestamp when printing it.

Reported-By: Dave Jones 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

printk: Implement some unlocked kmsg_dump functions

2012-07-21T17:34:00+00:00

If used from KDB, the locked variants are prone to deadlocks (suppose we
got to the debugger w/ the logbuf lock held).

So, we have to implement a few routines that grab no logbuf lock.

Yet we don't need these functions in modules, so we don't export them.

Signed-off-by: Anton Vorontsov 
Signed-off-by: Linus Torvalds

printk: Remove kdb_syslog_data

2012-07-21T17:34:00+00:00

The function is no longer needed, so remove it.

Signed-off-by: Anton Vorontsov 
Signed-off-by: Linus Torvalds

kmsg: merge continuation records while printing

2012-07-09T19:15:42+00:00

In (the unlikely) case our continuation merge buffer is busy, we unfortunately
can not merge further continuation printk()s into a single record and have to
store them separately, which leads to split-up output of these lines when they
are printed.

Add some flags about newlines and prefix existence to these records and try to
reconstruct the full line again, when the separated records are printed.

Reported-By: Michael Neuling 
Cc: Dave Jones 
Cc: Linus Torvalds 
Tested-By: Michael Neuling 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

kmsg: /proc/kmsg - support reading of partial log records

2012-07-09T17:05:10+00:00

Restore support for partial reads of any size on /proc/kmsg, in case the
supplied read buffer is smaller than the record size.

Some people seem to think is is ia good idea to run:
  $ dd if=/proc/kmsg bs=1 of=...
as a klog bridge.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44211
Reported-by: Jukka Ollila 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

kmsg: make sure all messages reach a newly registered boot console

2012-07-06T16:50:09+00:00

We suppress printing kmsg records to the console, which are already printed
immediately while we have received their fragments.

Newly registered boot consoles print the entire kmsg buffer during
registration. Clear the console-suppress flag after we skipped the record
during its first storage, so any later print will see these records as usual.

Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

kmsg: properly handle concurrent non-blocking read() from /proc/kmsg

2012-07-06T16:50:09+00:00

The /proc/kmsg read() interface is internally simply wired up to a sequence
of syslog() syscalls, which might are racy between their checks and actions,
regarding concurrency.

In the (very uncommon) case of concurrent readers of /dev/kmsg, relying on
usual O_NONBLOCK behavior, the recently introduced mutex might block an
O_NONBLOCK reader in read(), when poll() returns for it, but another process
has already read the data in the meantime. We've seen that while running
artificial test setups and tools that "fight" about /proc/kmsg data.

This restores the original /proc/kmsg behavior, where in case of concurrent
read()s, poll() might wake up but the read() syscall will just return 0 to
the caller, while another process has "stolen" the data.

This is in the general case not the expected behavior, but it is the exact
same one, that can easily be triggered with a 3.4 kernel, and some tools
might just rely on it.

The mutex is not needed, the original integrity issue which introduced it,
is in the meantime covered by:
  "fill buffer with more than a single message for SYSLOG_ACTION_READ"
  116e90b23f74d303e8d607c7a7d54f60f14ab9f2

Cc: Yuanhan Liu 
Acked-by: Jan Beulich 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

kmsg: add the facility number to the syslog prefix

2012-07-06T16:50:09+00:00

After the recent split of facility and level into separate variables,
we miss the facility value (always 0 for kernel-originated messages)
in the syslog prefix.

On Tue, Jul 3, 2012 at 12:45 PM, Dan Carpenter  wrote:
> Static checkers complain about the impossible condition here.
>
> In 084681d14e ('printk: flush continuation lines immediately to
> console'), we changed msg->level from being a u16 to being an unsigned
> 3 bit bitfield.

Cc: Dan Carpenter 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

kmsg: escape the backslash character while exporting data

2012-07-06T16:50:09+00:00

Non-printable characters in the log data are hex-escaped to ensure safe
post processing. We need to escape a backslash we find in the data, to be
able to distinguish it from a backslash we add for the escaping.

Also escape the non-printable character 127.

Thanks to Miloslav Trmac for the heads up.

Reported-by: Michael Neuling 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman