• Kay Sievers's avatar
    kmsg: properly handle concurrent non-blocking read() from /proc/kmsg · cb424ffe
    Kay Sievers authored
    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"
      116e90b2
    
    Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
    Acked-by: default avatarJan Beulich <jbeulich@suse.com>
    Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    cb424ffe
printk.c 64.6 KB