Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200622030222.1370098-1-Jason@zx2c4.com> <CAHk-=wj5TPoHih-8m+s9UNShiKavUFLacmHFmNbDrXQem43kSA@mail.gmail.com>
 <20200622133747.GD2850@glitch>
In-Reply-To: <20200622133747.GD2850@glitch>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 22 Jun 2020 09:42:25 -0700
Message-ID: <CAHk-=wgR8TZi_M4p3PZQh5nGjUjNBeXqhGyxUe8eykyf8g6p=A@mail.gmail.com>
Subject: Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"
To:     Bruno Meneguele <bmeneg@redhat.com>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Petr Mladek <pmladek@suse.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        David Laight <David.Laight@aculab.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jun 22, 2020 at 6:38 AM Bruno Meneguele <bmeneg@redhat.com> wrote:
>
> However, the issue with glibc is their fd checking on dprintf using:
>
> lseek(offset == 0, whence == SEEK_CUR)
>
> Which, technically, isn't a relative seek operation in my opinion, thus
> I'm also not sure that returning EINVAL is correct.

Well, I'm not sure there is a "correct". Normal file descriptors are
seekable or not, this is kind of a special one. It's not like you can
read it byte for byte anyway.

There is a "historical behavior".

> Would it make sense to return the next buffer index instead? Basically
> the same as SEEK_END does? The first "if (offset)" in the function would
> prevent any real relative move while SEEK_CUR would return a valid
> address following this buffer behavior of specific points it could seek
> to.

Maybe. At the same time, the way we don't actually return a real
position means that that's very dangerous too. We'll always return
"we're at position zero".

And we never accept byte-by-byte reads and require a "get the whole
record" model.

So I think we might as well accept "kmsg is special".

I don't have hugely strong opinions on it - I certainly agree that
"SEEK_CUR with offset zero could be a no-op", but I also don't think
there's a huge reason to try to change it, considering just _how_
special kmsg is.

               Linus