Messages in this thread | | | From | Kay Sievers <> | Date | Sun, 8 Jul 2012 15:06:20 +0200 | Subject | Re: Bug 44211 - /proc/kmsg does not (always) block for 1-byte reads |
| |
On Sun, Jul 8, 2012 at 2:59 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> The patch will not fix the underlying problem, but just make it behave >> more like it was and allow partial message reads. This is a years old >> problem, the net is full of bugreports of stuff going wrong with >> running dd bs=1 on /proc/kmsg. It is a really stupid idea, and can not >> work for many other reasons too. The interface can not safely be used >> that way, it does not have the usual semantics, it always returned 0 >> for read() whenever it needed to. > > If you are breaking the semantics perhaps that should also get fixed ?
I hopefully just restored the old semantics now.
Fixing it properly would be a bigger code change, and it can't use the far-too-simple tunneling through the syslog() syscall to feed /proc/kmsg.
If the seq_file interface could be used, that would probably be the best option, but I have no good idea how to make blocking reads, and concurrent non-blocks work with the seq_file stuff.
This is how read() in /proc/kmsg works and it is not protected by a lock or anything, and there is a not too small window between the check and the action. Things just go wrong if there is more than a single reader, but that was the case since forever.
static ssize_t kmsg_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { if ((file->f_flags & O_NONBLOCK) && !do_syslog(SYSLOG_ACTION_SIZE_UNREAD, NULL, 0, SYSLOG_FROM_FILE)) return -EAGAIN; return do_syslog(SYSLOG_ACTION_READ, buf, count, SYSLOG_FROM_FILE); }
Thanks, Kay
| |