[lkml]   [2012]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] kmsg: properly handle concurrent non-blocking read() from /proc/kmsg
>>> Kay Sievers <> 07/03/12 8:17 PM >>>
>From: Kay Sievers <>
>Subject: 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"
>Cc: Yuanhan Liu <>
>Cc: Jan Beulich <>
>Signed-off-by: Kay Sievers <>

This being a revert of all but a single change of
4a77a5a06ec66ed05199b301e7c25f42f979afdc, which I had suggested to
be reverted anyway:

Acked-by: Jan Beulich <>

 \ /
  Last update: 2012-07-04 09:01    [W:0.045 / U:2.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site