Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"

[Linus Torvalds]

On Sun, Jun 21, 2020 at 8:02 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809.
>
> This commit broke userspace. Bash uses ESPIPE to determine whether or
> not the file should be read using "unbuffered I/O", which means reading
> 1 byte at a time instead of 128 bytes at a time.

Ack. Somewhat odd behavior, but clearly user space depended on the
legacy "return EINVAL rather than ESPIPE" behavior.

I do think there are other reasons to not return ESPIPE. The fact is,
the printk buffer _is_ seekable, it's just relative seeking that
doesn't work. You can seek to the beginning and the end and a
particular offset, just not relative.

So I kind of see why people wanted to return ESPIPE, but at the same
time it really is very misleading: ESPIPE is for pure streams that
can't lseek at all.

The fact that some silly shell internal then reacts very badly to that
may be extreme, but it may be as well as you can do it you worry about
leaving data for the next user.

I've applied the revert.

             Linus