From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755711AbcITRag (ORCPT ); Tue, 20 Sep 2016 13:30:36 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58174 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbcITRaf (ORCPT ); Tue, 20 Sep 2016 13:30:35 -0400 Date: Tue, 20 Sep 2016 18:30:33 +0100 From: Al Viro To: Jan Stancek Cc: linux-kernel@vger.kernel.org Subject: Re: [bug] pwritev02 hang on s390x with 4.8.0-rc7 Message-ID: <20160920173033.GO2356@ZenIV.linux.org.uk> References: <57E131E6.1090507@redhat.com> <20160920150657.GN2356@ZenIV.linux.org.uk> <570490469.234828.1474391501934.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570490469.234828.1474391501934.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 20, 2016 at 01:11:41PM -0400, Jan Stancek wrote: > I ran all syscalls tests from LTP, and I see a change in behaviour > of couple other tests (writev01, writev03 and writev04 [1]) in 4.8.0-rc7. > > These call writev() with partially invalid iovecs, and now fail with > EFAULT, while with previous -rc6 kernel they returned number of bytes > written before they encountered invalid iovec record. > This should be reproducible also on x86. Known, discussed and considered legitimate. It's not so much EFAULT vs short write, it's how far do we shorten the write. Change consists of removing an accidental (and undocumented) property of iovec boundaries wrt write shortening. Usually an invalid address anywhere in the data we are asked to write leads to write shortened to the last pagecache boundary (i.e file position multiple of page size) entirely covered by valid data. It is filesystem-dependent and already deep in nasal demon territory. writev, pretty much by accident, never shortened past an iovec boundary. That's what got changed - now the rules are same as they are for all writes. Having an LTP test (as opposed to actual real-world code) deliberately stepping into that and checking how far does the shortening go means just one thing: update the test.