LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Bruno Meneguele <bmeneg@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	pmladek@suse.com, sergey.senozhatsky@gmail.com,
	rostedt@goodmis.org
Subject: Re: [PATCH] kernel/printk: add kmsg SEEK_CUR handling
Date: Tue, 17 Mar 2020 11:03:26 +0900	[thread overview]
Message-ID: <20200317020326.GC219881@google.com> (raw)
In-Reply-To: <20200313110229.GI13406@glitch>

On (20/03/13 08:02), Bruno Meneguele wrote:
> 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;
> 
> With that, if the seek fails, but return anything other than ESPIPE the
> dprintf() will also fail returning -EINVAL to dprintf() caller. While if
> ESPIPE is returned, it's "ignored" and the call still works. The way we
> have today make kmsg an exception case among the rest of the system
> files where you can open with dprintf.
> 
> One of the things I could agree with is removing the SEEK call from
> dprintf, since fprintf basically follows the same steps, but doesn't
> seek anything.  But at the same time, IMO it makes sense to make kmsg
> interface complaint with the errno return values.

The code in questions is very old. So let's add the missing bit to the
kernel. At the same time, we probably can have a slightly more detailed
documentation / code comment.

	-ss

  parent reply	other threads:[~2020-03-17  2:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13  0:35 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
2020-03-17  2:03     ` Sergey Senozhatsky [this message]
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=20200317020326.GC219881@google.com \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=bmeneg@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=stable@vger.kernel.org \
    --subject='Re: [PATCH] kernel/printk: add kmsg SEEK_CUR handling' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).