From: Bruno Meneguele <bmeneg@redhat.com>
To: David Laight <David.Laight@aculab.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"pmladek@suse.com" <pmladek@suse.com>,
"sergey.senozhatsky@gmail.com" <sergey.senozhatsky@gmail.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>
Subject: Re: [PATCH] kernel/printk: add kmsg SEEK_CUR handling
Date: Fri, 13 Mar 2020 10:06:34 -0300 [thread overview]
Message-ID: <20200313130634.GJ13406@glitch> (raw)
In-Reply-To: <b9427c068f3f4af9bf2bd290d88f84b9@AcuMS.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
On Fri, Mar 13, 2020 at 11:06:42AM +0000, David Laight wrote:
> From: Bruno Meneguele
> > Sent: 13 March 2020 11:02
> > On Fri, Mar 13, 2020 at 04:34:25PM +0900, Sergey Senozhatsky wrote:
> > > On (20/03/12 21:35), Bruno Meneguele wrote:
> > > >
> > > > Userspace libraries, e.g. glibc's dprintf(), expect the default return value
> > > > for invalid seek situations: -ESPIPE, but when the IO was over /dev/kmsg the
> > > > current state of kernel code was returning the generic case of an -EINVAL.
> > > > Hence, userspace programs were not behaving as expected or documented.
> > > >
> > >
> > > Hmm. I don't think I see ESPIPE in documentation [0], [1], [2]
> > >
> > > [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html
> > > [1] http://man7.org/linux/man-pages/man3/dprintf.3p.html
> > > [2] http://man7.org/linux/man-pages/man3/fprintf.3p.html
> > >
> > > -ss
> > >
> >
> > Ok, I poorly expressed the notion of "documentantion". The userspace
> > doesn't tell about returning -ESPIPE, but to the functions work properly
> > they watch for -ESPIPE returning from the syscall. For instance, gblic
> > dprintf() implementation:
> >
> > dprintf:
> > __vdprintf_internal:
> > _IO_new_file_attach:
> >
> > if (_IO_SEEKOFF (fp, (off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT)
> > == _IO_pos_BAD && errno != ESPIPE)
> > return NULL;
>
> Someone explain why it is doing an explicit seek to the current position?
> The only reason to do that is to get the current offset.
>
> David
>
dprintf gets a fd as input and convert it to a FILE structure, with that
it can't garantuee the previous state of that fd: was it already
manipulated? Thus they check the current position to make sure it's not
junk.
But that's me guessing things about a code from 1996 :).
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-13 13:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 0:35 [PATCH] kernel/printk: add kmsg SEEK_CUR handling Bruno Meneguele
2020-03-13 7:22 ` Greg KH
2020-03-13 10:44 ` Bruno Meneguele
2020-03-13 7:34 ` Sergey Senozhatsky
2020-03-13 11:02 ` Bruno Meneguele
2020-03-13 11:06 ` David Laight
2020-03-13 13:06 ` Bruno Meneguele [this message]
2020-03-17 2:03 ` Sergey Senozhatsky
2020-03-17 8:53 ` Bruno Meneguele
2020-03-19 10:33 ` Bruno Meneguele
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=20200313130634.GJ13406@glitch \
--to=bmeneg@redhat.com \
--cc=David.Laight@aculab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.