Messages in this thread | | | Date | Wed, 04 Jul 2012 07:22:34 +0100 | From | "Jan Beulich" <> | Subject | Re: [PATCH] kmsg: properly handle concurrent non-blocking read() from /proc/kmsg |
| |
>>> Kay Sievers <kay@vrfy.org> 07/03/12 8:17 PM >>> >From: Kay Sievers <kay@vrfy.org> >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" >116e90b23f74d303e8d607c7a7d54f60f14ab9f2 > >Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com> >Cc: Jan Beulich <JBeulich@suse.com> >Signed-off-by: Kay Sievers <kay@vrfy.org>
This being a revert of all but a single change of 4a77a5a06ec66ed05199b301e7c25f42f979afdc, which I had suggested to be reverted anyway:
Acked-by: Jan Beulich <jbeulich@suse.com>
| |