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 26EF3C6379F for ; Fri, 3 Feb 2023 16:23:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 976B16B0075; Fri, 3 Feb 2023 11:23:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9266C6B0078; Fri, 3 Feb 2023 11:23:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8176A6B007B; Fri, 3 Feb 2023 11:23:42 -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 74FA96B0075 for ; Fri, 3 Feb 2023 11:23:42 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4A5021C6B90 for ; Fri, 3 Feb 2023 16:23:42 +0000 (UTC) X-FDA: 80426501484.22.CD00E56 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf16.hostedemail.com (Postfix) with ESMTP id 631BA180020 for ; Fri, 3 Feb 2023 16:23:38 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf16.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675441420; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3f6K9jmea2c+BsvGl6nfD56JS6J54npdPU0KFuo1+Xo=; b=WGg0MVVhPKBIpD1LGRr+tcCJF+S54fu6OJYfxvVt+mq0hzhbmbxbajmtf6t7Mbk+0+XtGJ 7MIcoq/QTXn1BtkCPMJQUbpJCRZ/Zz3/jFa/zUVvcwwRqQdci4y5KxNu3902p03Mhk86op Sz5ly32vUY4Nlm8Q8b/3xMkNj+X4Lx4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf16.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675441420; a=rsa-sha256; cv=none; b=Pcoq277ypUpZLzeZlDk4kEkDpF+w79c/H/t0PShgjMtozsCj3XSqj8ZOgwloQQgsCGsRlE AtviYQmmBspskw+38338Ig343Avy/R8SoLjSZbgtlc3mObDiF2eSQrgocNf3R68ZdwKcm4 d78y57pZgwxgArEEmpXSzw3/h3CpUxc= Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-243-_ITs-rZGN66msvzu-eXIpg-1; Fri, 03 Feb 2023 16:23:33 +0000 X-MC-Unique: _ITs-rZGN66msvzu-eXIpg-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Fri, 3 Feb 2023 16:23:32 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.045; Fri, 3 Feb 2023 16:23:32 +0000 From: David Laight To: 'Matthew Wilcox' , Andreas Dilger CC: "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 Thread-Topic: [PATCH 0/5] Fix a minor POSIX conformance problem Thread-Index: AQHZN9J6uHKWfdvyUUW8SEkwX3xBiK69ZXmQ Date: Fri, 3 Feb 2023 16:23:32 +0000 Message-ID: References: <20230202204428.3267832-1-willy@infradead.org> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 631BA180020 X-Rspam-User: X-Stat-Signature: hqf33kijgfapcn6e7dkgzoxpk8tba64a X-HE-Tag: 1675441418-264600 X-HE-Meta: U2FsdGVkX1/pheU8Z1OZZcSpKxagG66uarYS2Tfn1fJZjI098jo9h6bjKvEzjkWdXFWsMMAkZJ8/0XXEGh0xNi5YnYoQ2B83r7QCf5rY+xh0SC7kqrGatwOWSsxlxdbIYKkxuvJQxuXZzmL0mVRj4CDZkdE0kjc+J9xw4OzH2FLAR4Lzipjdmcbzealx3u2Ld/hIdwJxKwuWza97poxK9TXfpGHG/uriVS8ktTNuwqxmSvgtINWGx0VxnKCeK0kJVWAhoPc1W8aFR964N6RuKdmqHGjz1pFPKVCrPlvaF9MeEyvCvgmUVHvjgQjj7uvJwjXPl5F9RaELeJLtOmh3cM17VJBybnoS8vPwLkrKiYFclVEFd4VBygYC9IXMazkYu4wF+oaVzqgLvyGMF6fz2QCVxkI8ggN8Z4MSzCDkZg5V+VGOL1vkfe/yecY75zbYDFRJlUG/Cb54JkBtNOOgWeAlJjdbNDb9wb4Q3mrSigJZ29FEkQblBpwTCFQf4TD0omoOyg3mzditYzgh5qa3vEhZKNeXFMMJqcZ9XXuFyEfDePKXU20jh536tBhJD3R74GOAOfIFN8UFlfKgg9Awt4mP/ZY/T2RpRYBXfzp4nL5jUkGT/Fvl4uNKqsMaRnnQRu4WxvXWBsBqW6sMFKlciJVgVYoiLmcQqCvyv86CGlBBCi7yhdyqALSZ27z33XoUnmNO5KVMqw/ar8xg0ZxFRPR1lLFhygcrHIbR8CSBimIf5htprO4arCu8sefNftjerZzpKkP+lj9h6m1L4QlCjU5Ca5MFN1lxz8rq7dnCYO2yWsXHW4tgbh85vCk9JPXYsvH/gXOrmli+qFqgrzKuMqyV2R/mRHJtDWFRViemklQki/rLneuzjwmzj9ENTl73CpdL95uYEWyaBpig3qicQROfkZf0KIVkBhjSTfR1qDcIXxbx23UfQJfYIk3tbCsc/RHgE7zACUbiUwO2v4W CmkmjP85 rHd4jRVruLzB/10FEGwNo+z1UUXzEq1mposjrjXIHE7+PqvWPj9SwocZCD8v10frmFc1eUYvSxkqSTdTU049DXDYByciHv6F5Pn6zn9UKThTFOadYdmla4pAutaf+nd2gqywRHIINrmyh5P1olVncUi0vPa6ycXx1mkGjuE5g4LQM8G86Dfn9EbBa345JOPFi1UjMPC6/frvr9SAU4NhHzLkKisTgYUtElMYGGXNp1jL36mnFbp+0tMIT9sVsrTa8RDrdrRzqqbv3IZJc2ihyyt/mCzb0LTgz7otkyY9yHuILat5VkgffZxSKyiHQ/n9U2Bh482A4kp35W7GRJxVP9+P/YWYB8aprcgFeqqyt+jQ/1eoJoYeb2EMkHb+SW+iZcLSkpTvCRsnloE8= 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: From: Matthew Wilcox > Sent: 03 February 2023 13:21 >=20 > On Thu, Feb 02, 2023 at 04:08:49PM -0700, Andreas Dilger wrote: > > On Feb 2, 2023, at 1:44 PM, Matthew Wilcox (Oracle) wrote: > > > > > > POSIX requires that on ftruncate() expansion, the new bytes must read > > > as zeroes. If someone's mmap()ed the file and stored past EOF, for > > > most filesystems the bytes in that page will be not-zero. It's a > > > pretty minor violation; someone could race you and write to the file > > > between the ftruncate() call and you reading from it, but it's a bit > > > of a QOI violation. > > > > Is it possible to have mmap return SIGBUS for the writes beyond EOF? >=20 > Well, no. The hardware only tells us about accesses on a per-page > basis. We could SIGBUS on writes that _start_ after EOF, but this > test doesn't do that (it starts before EOF and extends past EOF). > And once the page is mapped writable, there's no page fault taken > for subsequent writes. >=20 > > On the one hand, that might indicate incorrect behavior of the applicat= ion, > > and on the other hand, it seems possible that the application doesn't > > know it is writing beyond EOF and expects that data to be read back OK? >=20 > POSIX says: >=20 > "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." >=20 > 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(). 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! =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)