From: "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@nokia.com>
To: Mike Crowe <mac@mcrowe.com>,
Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Kay Sievers <kay@vrfy.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Re: kmsg: lseek errors confuse glibc's dprintf
Date: Thu, 21 Mar 2019 13:37:32 +0000 [thread overview]
Message-ID: <1f2823a1-8e4c-4103-ec02-2db1e9ed4a97@nokia.com> (raw)
In-Reply-To: <20190321123822.npfxumj2gwlwkxlf@mcrowe.com>
Hi!
On 21/03/2019 13:38, Mike Crowe wrote:
[...]
> I don't mind rebasing my patch once I know which of my two solutions is
> preferred. It seems that the -ESPIPE one is the current favourite.
I think:
1. Since Linux v4.8 (!user) case in not possible any more if the device
file was opened in write-only mode, so you are probably safe to omit this
chunk at all.
2. Nothing comes to my mind, what one could return as "current position"
from the lseek() call on /dev/kmsg. So without good idea what to return,
supporting offset == 0 (the only thing we ever can support on SEEK_CUR)
makes no sense to me.
Documentation/ABI/testing/dev-kmsg makes no promise on SEEK_CUR either,
therefore I'd say, -ESPIPE unconditionally is the right choice.
>>>> >From what I can tell prior to Kay Sievers printk record commit
>>> e11fea92e13fb91c50bacca799a6131c81929986, calling lseek(fd, 0, SEEK_CUR)
>>> with such a file descriptor would not return an error.
>>>
>>> Prior to Kay's change, Arnd Bergmann's commit
>>> 6038f373a3dc1f1c26496e60b6c40b164716f07e seemed to go to some lengths to
>>> preserve the successful return code rather than returning (the perhaps more
>>> logical) -ESPIPE.
>>>
>>> glibc is happy with either a successful return or -ESPIPE.
>>>
>>> For maximum compatibility it seems that success should be returned but
>>> given Kay's new seek interface perhaps this isn't helpful.
>>>
>>> This patch ensures that such a seek succeeds:
>>>
>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>>> index 02d6b6d..b3ff6f0 100644
>>> --- a/kernel/printk/printk.c
>>> +++ b/kernel/printk/printk.c
>>> @@ -693,7 +693,7 @@ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence)
>>> loff_t ret = 0;
>>>
>>> if (!user)
>>> - return -EBADF;
>>> + return (whence == SEEK_CUR) ? 0 : -EBADF;
>>> if (offset)
>>> return -ESPIPE;
>>>
>>> @@ -718,6 +718,11 @@ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence)
>>> user->idx = log_next_idx;
>>> user->seq = log_next_seq;
>>> break;
>>> + case SEEK_CUR:
>>> + /* For compatibility with userspace requesting the
>>> + * current file position. */
>>> + ret = 0;
>>> + break;
>>> default:
>>> ret = -EINVAL;
>>> }
>>>
>>> (although it could be argued that the !user case should return -ESPIPE
>>> rather than EBADF since the file descriptor _is_ valid.)
>>>
>>> and this patch causes a failure that glibc is prepared to accept:
>>>
>>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>>> index 02d6b6d..f6b0c93 100644
>>> --- a/kernel/printk/printk.c
>>> +++ b/kernel/printk/printk.c
>>> @@ -693,7 +693,7 @@ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence)
>>> loff_t ret = 0;
>>>
>>> if (!user)
>>> - return -EBADF;
>>> + return -ESPIPE;
>>> if (offset)
>>> return -ESPIPE;
>>>
>>> @@ -718,6 +718,11 @@ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence)
>>> user->idx = log_next_idx;
>>> user->seq = log_next_seq;
>>> break;
>>> + case SEEK_CUR:
>>> + /* For compatibility with userspace expecting SEEK_CUR
>>> + * to not yield EINVAL. */
>>> + ret = -ESPIPE;
>>> + break;
>>> default:
>>> ret = -EINVAL;
>>> }
>>>
>>> Either makes dprintf work, but is either the right solution?
>
> Mike.
>
--
Best regards,
Alexander Sverdlin.
prev parent reply other threads:[~2019-03-21 13:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 17:31 Mike Crowe
2015-01-23 23:09 ` Andrew Morton
2015-01-30 18:20 ` Mike Crowe
2019-03-21 9:47 ` Alexander Sverdlin
2019-03-21 10:33 ` Arnd Bergmann
2019-03-21 21:14 ` Mike Crowe
2019-03-21 12:38 ` Mike Crowe
2019-03-21 13:37 ` Sverdlin, Alexander (Nokia - DE/Ulm) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f2823a1-8e4c-4103-ec02-2db1e9ed4a97@nokia.com \
--to=alexander.sverdlin@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.sverdlin@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mac@mcrowe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®