From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935107AbcIPN0R (ORCPT ); Fri, 16 Sep 2016 09:26:17 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:59314 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934833AbcIPNZZ (ORCPT ); Fri, 16 Sep 2016 09:25:25 -0400 Date: Fri, 16 Sep 2016 14:25:14 +0100 From: One Thousand Gnomes To: Al Viro Cc: Mike Marshall , Linus Torvalds , LKML , linux-fsdevel Subject: Re: [RFC] writev() semantics with invalid iovec in the middle Message-ID: <20160916142514.0da379c4@lxorguk.ukuu.org.uk> In-Reply-To: <20160915222935.GI2356@ZenIV.linux.org.uk> References: <20160914213457.GG2356@ZenIV.linux.org.uk> <20160915222935.GI2356@ZenIV.linux.org.uk> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Unfortunately, some of LTP writev tests end up checking that writev() does > behave that way - they feed it a three-element iovec with shorter-than-page > segments, the second of which is all invalid. And they check that the > entire first segment had been written. 1003.1 says "Each iovec entry specifies the base address and length of an area in memory from which data should be written. The writev() function shall always write a complete area before proceeding to the next." and I imagine that is what LTP is attempting to test. The moment you pass an invalid address you are in the land of undefined behaviour, so I would read the standard as actually trying to deal with the behaviour in defined situations (eg out of disk space mid writev()). Alan