]> git.baikalelectronics.ru Git - kernel.git/commit
kmsg: properly handle concurrent non-blocking read() from /proc/kmsg
authorKay Sievers <kay@vrfy.org>
Fri, 6 Jul 2012 16:50:09 +0000 (09:50 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 6 Jul 2012 16:50:09 +0000 (09:50 -0700)
commit67ed039daa6736c00a022813cc0856e9dce45a26
tree5cc5ff53498de2f5bd8262a467fdd39454360cdc
parent17aab7ecdd4d2088f94769ae550349a8ca77ef5d
kmsg: properly handle concurrent non-blocking read() from /proc/kmsg

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"
  632d954719dbe1eeb38db62cdaef183ec1ce7fe6

Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/printk.c