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 EA419C05027 for ; Fri, 3 Feb 2023 12:59:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0CDB6B0072; Fri, 3 Feb 2023 07:59:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBBF76B0073; Fri, 3 Feb 2023 07:59:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5C966B0074; Fri, 3 Feb 2023 07:59:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B6CEB6B0072 for ; Fri, 3 Feb 2023 07:59:07 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 783DC1A06C4 for ; Fri, 3 Feb 2023 12:59:07 +0000 (UTC) X-FDA: 80425985934.30.FEF1439 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 0AB88A0011 for ; Fri, 3 Feb 2023 12:59:04 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bcQ4TtAK; spf=pass (imf15.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675429145; a=rsa-sha256; cv=none; b=gn2nFPZzt7uHzKZHaacekbsLmx+oWoRw54avafG1DU4aL5lYWDpoiuDJsGx5l4ENKrzwyC /jkzgDCxXPYwrrd29FeMJrtepRE1kM5npgQANkZpWQnxRrgh4eM+7dJ1l9fnozf/0e/WeT k0gZtXuH2DUN3EVXwPn6zYDU8boLxug= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bcQ4TtAK; spf=pass (imf15.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675429145; 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=D/GfsblX7fiP9DoE1ZO7fPATr7amcWgTVW69Pie1Ifo=; b=GvNEgr1Rv/1QP1+VQj2vCTW2fKtdabht+EuExKhG9//9twfNQpUxRUiPFKsElGlvQd0oz1 dTZ8kqmCbhwsiRkaFyAd7d+hICIu3AphNcLFrhzckFZFLjQyRwNP9XVDYNwQvjyJcMTORY DhJh5wY/wiaYGus/l6JBt5S8acivF7o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675429144; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D/GfsblX7fiP9DoE1ZO7fPATr7amcWgTVW69Pie1Ifo=; b=bcQ4TtAK//DTdGyPJXhcQ/EsNSQCoJpUq1TYxJ6QyUnM4AiaXuBIMTvwIGqconnvFeoqLe 2ZmvMTcSwF/9vtgDYT7nPT1C8MBKBFEPm7pg8TscL7ywHC738GK9eFpE9zIvAEOMlBSNkr MkgOQHmeUIYWXc5PNHxWQETEd/PeZ7A= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-636-nfMTt12KMRGmcrQ95ZsBiQ-1; Fri, 03 Feb 2023 07:59:03 -0500 X-MC-Unique: nfMTt12KMRGmcrQ95ZsBiQ-1 Received: by mail-qv1-f70.google.com with SMTP id jo26-20020a056214501a00b0053aa15f61d4so2683259qvb.7 for ; Fri, 03 Feb 2023 04:59:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=D/GfsblX7fiP9DoE1ZO7fPATr7amcWgTVW69Pie1Ifo=; b=fDxu6pe8XmCHLIO5vZ2g+juMeyPdGNBubuVA0phK6Ta8pl2fzgrtmnZHMUcovqC+RH XxNHoHwBTJv/1Rr0E3Fq7BdhbS+urbIHZloZkh2Ai4+GDerY0MQmoPcMlBdFagJXB7Sf UOITlT0Rc3bFYL4iFbHd/d8PV3ba2PELjlB6qB6MMiHrIZBJIa44w3MSdSRoPG5nc/uo xwDFHjRxU0EInl7Cuoj7KFpLOyb3+bZWwmQvFQUkd/PhkTjiD4ug4wzm3T82VQn5LYeI yIUIGe4q/MLPaXJ2+3x9wSQgrbWTJnlaoqVRlNCbCZ4lMQyOAjq6UbqwOo2VhtEodHiO fFeA== X-Gm-Message-State: AO0yUKUASHVjRA37xPhce1Ga+zo6o8l3aI3uQzJW+ciCD9vu9oJgK/t6 7+FDaNnPod0K16fFpeqW0gAzUC1N93xaC5ooJJhoxvLS3co5h614N3iA8LzD1n7lkUAal1AGa1Y UY7lNJGedWFE= X-Received: by 2002:ac8:58cd:0:b0:3b8:2b4e:cbca with SMTP id u13-20020ac858cd000000b003b82b4ecbcamr18450056qta.14.1675429142840; Fri, 03 Feb 2023 04:59:02 -0800 (PST) X-Google-Smtp-Source: AK7set+JyEdhHV/y5OUx3a+8bJXzRzBigiwKr1DH/5NMkcZ56KgssbeiFk8LATo8Xmxpy2fqUTwKEQ== X-Received: by 2002:ac8:58cd:0:b0:3b8:2b4e:cbca with SMTP id u13-20020ac858cd000000b003b82b4ecbcamr18450031qta.14.1675429142619; Fri, 03 Feb 2023 04:59:02 -0800 (PST) Received: from bfoster (c-24-61-119-116.hsd1.ma.comcast.net. [24.61.119.116]) by smtp.gmail.com with ESMTPSA id x8-20020ae9e908000000b0072526a43ef7sm1689338qkf.120.2023.02.03.04.59.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 04:59:01 -0800 (PST) Date: Fri, 3 Feb 2023 08:00:16 -0500 From: Brian Foster To: "Matthew Wilcox (Oracle)" 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 1/5] truncate: Zero bytes after 'oldsize' if we're expanding the file Message-ID: References: <20230202204428.3267832-1-willy@infradead.org> <20230202204428.3267832-2-willy@infradead.org> MIME-Version: 1.0 In-Reply-To: <20230202204428.3267832-2-willy@infradead.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 0AB88A0011 X-Rspamd-Server: rspam01 X-Stat-Signature: 4d9qu4f1wthj543ekex7jnj4sit46txo X-HE-Tag: 1675429144-406721 X-HE-Meta: U2FsdGVkX1+GnYA+mbd8sPVYkIBp0GhCFsYTXAS6KBD8JHSpJQmmjFh1DSs27SimeRIEmPwhmfBxM1HrnC54cHx8X9bttCdhqG4o/byHZCitDrbtH8t8DJb5XcifqN928IILILMc3OsSyb3f1r5RoEm5/Vtq8WFti/IKliPfcxoiWnzvGxja9frH6ljQZUFJkIKTdvhKTUheiZIyf4j7VYj425jOC0Pv1RDmuqLhwGFwI2m24ayeLVbiR6JuaKDcuxsLi7B4obE/pJwlRMpszUtENvfRryqRr2MFwvxa5tCWxdynKMINbJzuXNboNHHgTmjLI+eGNxfSZvayxQoFlF+zwk5Ot42rOHWXhynhtCqrRNiFDJWvfmuYj7p0FuyDdDhj0lYzCedO61brIwevL0eAhAQJarcq8K+FMu8xvihOsEW7ICKxt/K6MgMx7eOBOo9mk/q27PZs65ZB4aNDo+4b1iSf/tcMr4tAmHMsnMZImJXcmtlpT9IL8jFRdkKfIiMtbao0vZjnwRKXfCWcSjqw2v4EsvApxFjQwIdQhP8p0ir0OPTrkp/pHnbRRslKathG5ZlFpDitJR6NGr5vupU4+wIp89F7yGtxLQt4xAQ9NnfTkep2Oh/s0UKh4Yfq/2lac7QYOcH4HUidfh4zoH2kjckuCCk0HxM14rN8O8lbgLuvMrnA/S0t2sUBEfCbvYgoRoG5qPwT9qRH8IeiE8T09KHdHqLAha8XyEQr2DvKkYZXXXJO08qMCnyoJO+gDs0P0psn5PqMYOOxPe+iTbqzYKyQf8vo+zQYun03zYa+yyZS4SK/m3T7kB0VpGfmGzjT1vSJFhAZbV/bFk7GiJeQOvC9LDs8zHTa9MQd20JUmsz2levDb+Kgx5FH+OdC0uNB8Y27EM1q9mk3LPCYmoWHGD37qAWxRNzez4M4s2RlNc+HiIySbYmfbFSdcn+MJ0Wt5AojteEaQPx6EWa pH6Tever L/2aO8iYSK9cVO9OXdDNg7cXvfmAFXQBP5Zc8vRzma0C/f4v/+WdyhhY1hLWuAq/sAgJX5lTzVzEeFe2QMocCzpCpZeZVxx25CNM0zWj9H/tdEZ/lqQN//UkDkE+c9RG+R1BDcFngxa96BQEQQ3dBwbXSQGDjuS0d5i/X9HBKUuxsAKdzcNBQW4yG243ZbPoz7+tnkqsy91g8odTYRmVCW165mG4IzHf9wPsbJ3XNwWXcyyxDhPpbGzfTV5r3H0nwkjG28+yQE/yT8CiiWEPV2Aodv/mL3EDRw7IepkoCkF4MT4Q2pLm7gBJYtw4MAcXjiTukeI/jY0fQuuXk3tP9mTyiNdgg3YMDl/RNfxBxCm/FrWZmyK6n0VD1mW/Tum8tE51x15BjowznaVaErPEVF/cSo/wWJgS7M1/akuvM9MOSW1l/kAEx5okIEw== 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 Thu, Feb 02, 2023 at 08:44:23PM +0000, Matthew Wilcox (Oracle) wrote: > POSIX requires that "If the file size is increased, the extended area > shall appear as if it were zero-filled". It is possible to use mmap to > write past EOF and that data will become visible instead of zeroes. > This fixes the problem for the filesystems which simply call > truncate_setsize(). More complex filesystems will need their own > patches. > > Signed-off-by: Matthew Wilcox (Oracle) > --- > mm/truncate.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/mm/truncate.c b/mm/truncate.c > index 7b4ea4c4a46b..cebfc5415e9a 100644 > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -763,9 +763,12 @@ void truncate_setsize(struct inode *inode, loff_t newsize) > loff_t oldsize = inode->i_size; > > i_size_write(inode, newsize); > - if (newsize > oldsize) > + if (newsize > oldsize) { > pagecache_isize_extended(inode, oldsize, newsize); > - truncate_pagecache(inode, newsize); > + truncate_pagecache(inode, oldsize); > + } else { > + truncate_pagecache(inode, newsize); > + } I don't think this alone quite addresses the problem. Looking at ext4 for example, if the eof page is dirty and writeback occurs between the i_size update (because writeback also zeroes the post-eof portion of the page) and the truncate_setsize() call, we end up with pagecache inconsistency because pagecache truncate doesn't dirty the page it zeroes. So for example, with this series plus a nefariously placed filemap_flush() in ext4_setattr(): # xfs_io -fc "truncate 1" -c "mmap 0 1k" -c "mwrite 0 10" -c "truncate 5" -c "mread -v 0 5" /mnt/file 00000000: 58 00 00 00 00 X.... # umount /mnt/; mount /mnt/ # xfs_io -c "mmap 0 1k" -c "mread -v 0 5" /mnt/file 00000000: 58 58 58 58 58 XXXXX Brian > } > EXPORT_SYMBOL(truncate_setsize); > > -- > 2.35.1 > >