mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Linux API <linux-api@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: writev error codes
Date: Thu, 19 Jan 2017 08:34:25 +0100	[thread overview]
Message-ID: <20170119073425.GC30786@dhcp22.suse.cz> (raw)
In-Reply-To: <CAKgNAkgWN6Fkx0UqE7Hu6RV82funbbP4OJM0yNK9wiE=0FAMxA@mail.gmail.com>

On Thu 19-01-17 15:09:52, Michael Kerrisk wrote:
> Hello Michal,
> 
> On 19 January 2017 at 04:44, Michal Hocko <mhocko@kernel.org> wrote:
> > Hi,
> > we have noticed that one of the LTP tests started to fail after
> > 99526912c934 ("fix iov_iter_fault_in_readable()"). The code has expected
> > EINVAL while it gets EFAULT. I believe the new behavior is reasonable,
> > but checking the man 2 writev, there is no mention about EFAULT,
> > and other errnos for that matter, so it seems this is rather under
> > documented and it can confuse users. LTP has been fixed in the meantime
> > [1] but this might come unexpected to others.
> >
> > In principle writev as a write
> > "multiplier" should be allowed all the error codes that write(2) allows,
> > right? I am not sure how we should reflect that. Either c&p what we have
> > in man 2 write or put a reference to it and only describe writev
> > specific, if there are any (I haven't checked that).
> >
> > [1] https://github.com/linux-test-project/ltp/commit/db19194527060a962955a7db54a2f5710e69bec9
> 
> Perhaps I am misunderstanding you, but in the writev(2) page there is the text:
> 
>     ERRORS
>        The  errors  are  as given for read(2) and write(2).  Furthermore,
>        preadv(), preadv2(), pwritev(), and pwritev2() can also  fail  for
>        the  same reasons as lseek(2).

This has hit right to the blind spot. Sorry about the noise!

> 
> And in the write(2) page, we have:
> 
>        EFAULT buf is outside your accessible address space.
> 
> Does this not cover the case you describe?

Yes

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-01-19  7:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 15:44 Michal Hocko
2017-01-19  2:09 ` Michael Kerrisk (man-pages)
2017-01-19  7:34   ` Michal Hocko [this message]
2017-01-19  2:47 ` Al Viro

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=20170119073425.GC30786@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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

Powered by JetHome