From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D63A1C636D6 for ; Fri, 3 Feb 2023 16:29:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15BDB6B0074; Fri, 3 Feb 2023 11:29:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 10C756B0075; Fri, 3 Feb 2023 11:29:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3CDD6B0078; Fri, 3 Feb 2023 11:29:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E51836B0074 for ; Fri, 3 Feb 2023 11:29:46 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 82A1916093C for ; Fri, 3 Feb 2023 16:29:46 +0000 (UTC) X-FDA: 80426516772.27.7245909 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id AA9C440007 for ; Fri, 3 Feb 2023 16:29:44 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F5eJctUg; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675441784; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aKb0TcrT5HcwknHd0UpHTjJTmEsJjOCtGhiYiz34rX4=; b=N8ipNRX8Aig7XaI4X/tHrnwVgc7I0Qm84/JMRZKQmszfzampYmgLJWrs2T0ePDhyyEr0MY 45QQX59FvKLEeUP0oH3ncwUSK/lmjwwjxBXIDmj7qkWv+2WowShoPKeD8Y4Q7AaNDlwqjz 4Uy4cyBRl8M4jDt+58m7xpLfDad/ypY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F5eJctUg; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675441784; a=rsa-sha256; cv=none; b=jyZUd4xrUpPYJ7pFyhD4SabouhapEInwaS2+NWNBtXvHPM/s1FFgtvNZlSMNc+Q25q/oKM aSRBFTfZjL7CjkrJvvqzNdM+hUY6K7FRE0u+uKfqS3Fi63wcrPCcV9l2DwR6V138ZCNrPf SD4PUh5MXElUocPyqAjxxo4/oK2vQE0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aKb0TcrT5HcwknHd0UpHTjJTmEsJjOCtGhiYiz34rX4=; b=F5eJctUgZhs3Fw+CRoaIZxwLr5 QLrqqcy2wvllXqLy302hai+Ai+zxqMtdQx9W1Y6Tg0bhXD9arU5mgpKe+m44Lv82ov2FoiuUbAJA/ dpQ1p9lIfH8mpwUIT4GDlkGxJpgJic3E+5q0zA67mFwusHbShYPeBbitkBNAcMDBZaKtttUuTTkuI 5vwv1oZBMEEPZRd8nTxIyMCh5ELDr6k0hrsIwc0xaBR07opZesopKjVl+vut4xXKESSa5GzOgD1gt zifZLK3DMeyTLJwcNy1mg/3OVy6MIFZH5F7gKd50xvr3ldC4GrFIS0u7k+igKDP+YvGKkVYeryWiw Ws461cTw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNywV-00ESXM-OO; Fri, 03 Feb 2023 16:29:39 +0000 Date: Fri, 3 Feb 2023 16:29:39 +0000 From: Matthew Wilcox To: David Laight Cc: Andreas Dilger , "linux-fsdevel@vger.kernel.org" , "linux-afs@lists.infradead.org" , "linux-btrfs@vger.kernel.org" , "linux-ext4@vger.kernel.org" , "linux-mm@kvack.org" , Hugh Dickins , "linux-kernel@vger.kernel.org" , "fstests@vger.kernel.org" Subject: Re: [PATCH 0/5] Fix a minor POSIX conformance problem Message-ID: References: <20230202204428.3267832-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AA9C440007 X-Stat-Signature: y6ohmgrp4un46mxfakbp5adfaenu6hyb X-Rspam-User: X-HE-Tag: 1675441784-871706 X-HE-Meta: U2FsdGVkX18ypv29VnL+taYSDBa9iUN1Np2BDudrfkT7NoXEQh/oQjrFJs7N0vaAx2KPSvaJ+d06En0VUSTiTJIMrssDJUXFhbw46LWzwQE9/IQxWt+E0ydlQ/+CUHO6lXKrZCNlF4VE6Qb3we/AC4tMDYiFNOMR/2heDbbuqdztErXhqHi2kb756gLgs9BBh+P4thC52xZFSyt9GvVeaoHKekscdW69LCOyZjtQ2zkzGYJeRzc6r+ZaPeoCwcm5C5uTwMq4NF2UdElB5n6lzgVVY39AtpolWvJphYYpxJsdgTKphO7IvL8ZcULpr9U9o2WWHmEP0QKjSffmtJdt4Wz2yiueXeArGHAmq8qRYynKbHPynOn2jcZMRE3rbSCXMGJwQx4G8qt24dnJ42uAUWk+DYZYgVXRolciRSAeVtAUfpjC/Y6Kudw8osVxaUEHTcYpLwm7lQEGwNaCVhORNbRJJQTM03KyruAOWkUF2Ss+K9UJBRmwcofIAlfwG0RO9O6kL3bgJvaSuUrqw+49its3NZdAOPwJkJ7WDIJtIOkTEYsqVmxFBM9Qja25cTuBkrRACqdB7qufhgpU5hUBb7gNavHTcD49nvgCQuvfdVzwPWJ3s0JTzBFrXm57Gn1T/EyR68oJw5SLh1G02P6sJKVQ25sptM/+iBHfDfn0TjYFnb8jAJAwv8e6LaIQzpaeegMQFAlpw+OjSHZxMBJGedMSaMl7L9TuFI9yvUxiLNd5I+G13WoeKV4uvETT8aYxd8xb/iCuh4UN0vlQqRnzLQ2nWXd0nHHOgpCZ0q1f4zcTNl92WuanQKqQpwRqlK/ba0LcDZWwNdKZAlJoTpibTSXq+i+30WZ6xvrCCs4jQlypAnbzOAAvbaodzZFBMr2TyeFPR5tfR4swz7XUeGZEV4pzyxA/opPsykR3bhbAhpmPIaQLxZB8P298i2fKIvGT759NY2+16I4e+K5WDh2 c0MDyk9L /2RwzexBiphXoQ25lK0Nll4yefHFP73yq+5d0Obj0AIB4jM4ziNxea9hqVDhsZElAU62zIdTkAm8DIt+O3/4V5u2buwlCy5A2KUg8PHi9VYQ86K4rAVJELAPUCd+mreNr7EF2ffY672bTjSlDZ1Y4xj53L5tBUc+ovFGc/B9GhWpvP8urWR7AC86swaebiGT2yi7xReeOo2h/c9NtqOVxZ4BKDnKxTjINdhJMAPgcp5Uq5Yu3gIqsZLj/+w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 03, 2023 at 04:23:32PM +0000, David Laight wrote: > From: Matthew Wilcox > > "The system shall always zero-fill any partial page at the end of an > > object. Further, the system shall never write out any modified portions > > of the last page of an object which are beyond its end. References > > within the address range starting at pa and continuing for len bytes to > > whole pages following the end of an object shall result in delivery of > > a SIGBUS signal." > > > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html > > It also says (down at the bottom of the rational): > > "The mmap() function can be used to map a region of memory that is larger > than the current size of the object. Memory access within the mapping but > beyond the current end of the underlying objects may result in SIGBUS > signals being sent to the process. The reason for this is that the size > of the object can be manipulated by other processes and can change at any > moment. The implementation should tell the application that a memory > reference is outside the object where this can be detected; otherwise, > written data may be lost and read data may not reflect actual data in the > object." > > There are a lot of 'may' in that sentence. > Note that it only says that 'data written beyond the current eof may be > lost'. > I think that could be taken to take precedence over the zeroing clause > in ftruncate(). How can the _rationale_ (explicitly labelled as informative) for one function take precedence over the requirements for another function? This is nonsense. > I'd bet a lot of beer that the original SYSV implementation (on with the > description is based) didn't zero the page buffer when ftruncate() > increased the file size. > Whether anything (important) actually relies on that is an interesting > question! > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >