From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751184AbdASHzo (ORCPT ); Thu, 19 Jan 2017 02:55:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:45785 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdASHzZ (ORCPT ); Thu, 19 Jan 2017 02:55:25 -0500 Date: Thu, 19 Jan 2017 08:34:25 +0100 From: Michal Hocko To: "Michael Kerrisk (man-pages)" Cc: Linux API , Al Viro , LKML Subject: Re: writev error codes Message-ID: <20170119073425.GC30786@dhcp22.suse.cz> References: <20170118154431.GD7021@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 19-01-17 15:09:52, Michael Kerrisk wrote: > Hello Michal, > > On 19 January 2017 at 04:44, Michal Hocko 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