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 D7E2DCA0FEB for ; Fri, 30 Aug 2024 13:11:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F9DB6B014A; Fri, 30 Aug 2024 09:11:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 681E36B014B; Fri, 30 Aug 2024 09:11:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 522946B014C; Fri, 30 Aug 2024 09:11:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2F29F6B014A for ; Fri, 30 Aug 2024 09:11:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CF9EB121013 for ; Fri, 30 Aug 2024 13:11:55 +0000 (UTC) X-FDA: 82508949390.03.8D7D579 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf30.hostedemail.com (Postfix) with ESMTP id 0720480019 for ; Fri, 30 Aug 2024 13:11:53 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725023424; h=from:from:sender: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=PXEgAalT+YXMYOj51RI7E8XKvhjUxrw7lT9vis9Hbeo=; b=UATmIDwRVVhOU1G7Djo3WOVwPHEaO7Mbo1oX1QKGzXCY+YcoVbr6p9OZOLLwPJ91CBX9mT 99TdGlLaJdgTH3UaM+PnFSwHE5d9ZGXvGog19ySYukAgKaPW8JvF0vR6+b4rwZc9LpCc5K TV1rFRh+j2/snwM8kiAZWne+5zLdn7g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725023424; a=rsa-sha256; cv=none; b=RFp+HR7lk5BLUkBAWfYZFX5Tr7jfm2wYwI4COAz5TjKUc5A7MU+kodjndbmP0ZCZDYaZeW AyyEOwyTG6McX4sgA1923oq4eQX125YnqCmv547J1YsJWOieeIhTbjoPEZErn7ekot5Obe SyTyhxcDGS0JMSSy1/JLC5M5Rm+npS8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none Received: from [2601:18c:9101:a8b6:6e0b:84ff:fee2:98bb] (helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1sk1PY-000000002P5-33PK; Fri, 30 Aug 2024 09:11:32 -0400 Message-ID: <97ba80061354fef89349a70e1cb8eb34dd7730f3.camel@surriel.com> Subject: Re: [PATCH] mm,tmpfs: consider end of file write in shmem_is_huge From: Rik van Riel To: "Darrick J. Wong" Cc: Hugh Dickins , kernel-team@meta.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner , Vlastimil Babka Date: Fri, 30 Aug 2024 09:11:32 -0400 In-Reply-To: <20240830055244.GD6257@frogsfrogsfrogs> References: <20240829235415.57374fc3@imladris.surriel.com> <20240830055244.GD6257@frogsfrogsfrogs> Autocrypt: addr=riel@surriel.com; prefer-encrypt=mutual; keydata=mQENBFIt3aUBCADCK0LicyCYyMa0E1lodCDUBf6G+6C5UXKG1jEYwQu49cc/gUBTTk33Aeo2hjn4JinVaPF3zfZprnKMEGGv4dHvEOCPWiNhlz5RtqH3SKJllq2dpeMS9RqbMvDA36rlJIIo47Z/nl6IA8MDhSqyqdnTY8z7LnQHqq16jAqwo7Ll9qALXz4yG1ZdSCmo80VPetBZZPw7WMjo+1hByv/lvdFnLfiQ52tayuuC1r9x2qZ/SYWd2M4p/f5CLmvG9UcnkbYFsKWz8bwOBWKg1PQcaYHLx06sHGdYdIDaeVvkIfMFwAprSo5EFU+aes2VB2ZjugOTbkkW2aPSWTRsBhPHhV6dABEBAAG0HlJpayB2YW4gUmllbCA8cmllbEByZWRoYXQuY29tPokBHwQwAQIACQUCW5LcVgIdIAAKCRDOed6ShMTeg05SB/986ogEgdq4byrtaBQKFg5LWfd8e+h+QzLOg/T8mSS3dJzFXe5JBOfvYg7Bj47xXi9I5sM+I9Lu9+1XVb/r2rGJrU1DwA09TnmyFtK76bgMF0sBEh1ECILYNQTEIemzNFwOWLZZlEhZFRJsZyX+mtEp/WQIygHVWjwuP69VJw+fPQvLOGn4j8W9QXuvhha7u1QJ7mYx4dLGHrZlHdwDsqpvWsW+3rsIqs1BBe5/Itz9o6y9gLNtQzwmSDioV8KhF85VmYInslhv5tUtMEppfdTLyX4SUKh8ftNIVmH9mXyRCZclSoa6IMd635Jq1Pj2/Lp64tOzSvN5Y9zaiCc5FucXtB9SaWsgdmFuIFJpZWwgPHJpZWxAc3VycmllbC5jb20+iQE+BBMBAgAoBQJSLd2lAhsjBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDOed6ShMTeg4PpB/0ZivKYFt0LaB22ssWUrBoeNWCP1NY/lkq2QbPhR3agLB7ZXI97PF2z/5QD9 Fuy/FD/j ddPxKRTvFCtHcEzTOcFjBmf52uqgt3U40H9GM++0IM0yHusd9EzlaWsbp09vsAV2DwdqS69x9RPbvE/NefO5subhocH76okcF/aQiQ+oj2j6LJZGBJBVigOHg+4zyzdDgKM+jp0bvDI51KQ4XfxV593OhvkS3z3FPx0CE7l62WhWrieHyBblqvkTYgJ6dq4bsYpqxxGJOkQ47WpEUx6onH+rImWmPJbSYGhwBzTo0MmG1Nb1qGPG+mTrSmJjDRxrwf1zjmYqQreWVSFEt26tBpSaWsgdmFuIFJpZWwgPHJpZWxAZmIuY29tPokBPgQTAQIAKAUCW5LbiAIbIwUJEswDAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQznnekoTE3oOUEQgAsrGxjTC1bGtZyuvyQPcXclap11Ogib6rQywGYu6/Mnkbd6hbyY3wpdyQii/cas2S44NcQj8HkGv91JLVE24/Wt0gITPCH3rLVJJDGQxprHTVDs1t1RAbsbp0XTksZPCNWDGYIBo2aHDwErhIomYQ0Xluo1WBtH/UmHgirHvclsou1Ks9jyTxiPyUKRfae7GNOFiX99+ZlB27P3t8CjtSO831Ij0IpQrfooZ21YVlUKw0Wy6Ll8EyefyrEYSh8KTm8dQj4O7xxvdg865TLeLpho5PwDRF+/mR3qi8CdGbkEc4pYZQO8UDXUN4S+pe0aTeTqlYw8rRHWF9TnvtpcNzZw== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0720480019 X-Stat-Signature: co4wxucwyqxohm4cf7eggycczyfc6bz1 X-HE-Tag: 1725023513-928066 X-HE-Meta: U2FsdGVkX18OnCHn1FSltvFNb5MJ8Y81lQ+UrboqImLMlN2W1wU+8WfJmfKGc+rFVBqdqTpMa9YIDPT/xsJllM+OEhdTuODjP0KgAV9NE6qDBB5gi2sPPRVKgx+jt+VPriopO5wWSxdymK8Y2BbGYhT7MXsOda3sy0p7sLibIIl+hs6w6m5yUBzeUCxmbB+kffsW1r8dNkmVNsoYd1N+W0tdhMG6dHH/DMQM+kMSGbbY6Zzfy5vUXM/aTxaoo0zcYZ5DjfGVwq89JIYsqYFeDHRTpx+yo87hzY7OxmuHRZIG6N/yXDDj0KlB2y/fd+J8IGcLBoZ1jBsrbPenWQCAa4Ml2loYTcHK2fA+cG7Cm4aSKKnWzBssvSLCbxtdCFkluO+uqE+m3gBha7YKvby35Ba1HWqiW+ppeEVInn+Vw/RADIZvrr+bQ2pDquzW7+xUm7roXuJf+A3zfqmdyV0vjAw33wy19RCI1YEQXoFlC4YeXyAb0lkGh+nNkxoYLQfPvC0j7lqJrbEpnI6CN4wmFELaZqKXGGCpCh+zVLZxkqkL96e4/rZ3OoKZ4U9SHN3Qdqv/yVjXaZYsdpVIX2FZlRDMTjiKjWjfp3bi8sAtiJQpTV/0ap/H2kyr8nIf48/FX1E/cCzY/g61UKryfaWONwNZizSq/PMUhtoeziC8IrpG4XwJq/+OFMRXA5WHD//tpk1c0Xnr8uBFNP8CVUXwSRZiukxr2PMkt97KhRNww/PYAQfmOnuWg1soLlPPufL7xSv2eyYg/kOCWttOCzvGQbjr9tldVU5jEM3/qf/OgPEQVlSqHHKsdK95bPAhq+YXCw+3NI0Vzy/2Eu1WeZVGsI2fL4I6qju50kF8zkh3QZq0jEg/9CtI9XrPo5lVDB4SufwspSidf8h9q8/MUGTNPkPeXMGJmcOz4e3xN9TqA3EP56xJTNN/IwJQuchRcK4ZkhBFDGz8bU0USuMkKzt 4C1ESFmA clDSMS6c5AmVJWOqlqzVbmpophHCgTkAg07ofAY1zMBTdDTQN7m2qZmCS1sqouHdu+E13jUBzEQiPSUAHPfXe1j6eoYsSw88rVJ29nnWFhk0RQqTboVxUqHk0SyTJs9tt7sCAZJXvvxXCFPYo+A6vn+odBnG9G5rGiCkUn45fd6AMVrOxYMDTq3q1rO3Ag6CG2c/7AWR8lC6MdeArTa+WElvBcHPKWNp1DudLlq96bYzvrYRZHXBT8GH8REmcsl+Zbg2a3G34mmj8z1wDodC/Ewu7hAbuO8x8t419xqEmQpLe7BQfLKNHUZFQvApoAnL5iYnKKHiCfMDP/rBAqm3FkBy10g== 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: List-Subscribe: List-Unsubscribe: On Thu, 2024-08-29 at 22:52 -0700, Darrick J. Wong wrote: > On Thu, Aug 29, 2024 at 11:54:15PM -0400, Rik van Riel wrote: > >=20 > > @@ -196,7 +196,7 @@ xfile_store( > > =C2=A0 unsigned int len; > > =C2=A0 unsigned int offset; > > =C2=A0 > > - if (shmem_get_folio(inode, pos >> PAGE_SHIFT, > > &folio, > > + if (shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > &folio, >=20 > Technically speaking, the "0" here could be (pos + count), though for > the current xfile users this isn't likely to make much difference > because online fsck's index building only appends small amounts of > data > (i.e. not larger than a PAGE_SIZE) at a time. >=20 > > =C2=A0 SGP_CACHE) < 0) With SGP_CACHE, won't shmem_get_folio simply refuse to allocate any pages beyond the end of the inode? if (sgp <=3D SGP_CACHE && ((loff_t)index << PAGE_SHIFT) >=3D i_size_read(inode)) return -EINVAL; > > =C2=A0 break; > > =C2=A0 if (filemap_check_wb_err(inode->i_mapping, 0)) { > > @@ -267,7 +267,7 @@ xfile_get_folio( > > =C2=A0 i_size_write(inode, pos + len); > > =C2=A0 > > =C2=A0 pflags =3D memalloc_nofs_save(); > > - error =3D shmem_get_folio(inode, pos >> PAGE_SHIFT, &folio, > > + error =3D shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > &folio, >=20 > This 0 could be pos + len, since the only caller is xfarray_sort, > which > runs much faster when it can heapsort a large folio's worth of data > at a > time. >=20 > > =C2=A0 (flags & XFILE_ALLOC) ? SGP_CACHE : > > SGP_READ); The same applies here. > > =C2=A0 memalloc_nofs_restore(pflags); > > =C2=A0 if (error) > > diff --git a/fs/xfs/xfs_buf_mem.c b/fs/xfs/xfs_buf_mem.c > > index 9bb2d24de709..07bebbfb16ee 100644 > > --- a/fs/xfs/xfs_buf_mem.c > > +++ b/fs/xfs/xfs_buf_mem.c > > @@ -149,7 +149,7 @@ xmbuf_map_page( > > =C2=A0 return -ENOMEM; > > =C2=A0 } > > =C2=A0 > > - error =3D shmem_get_folio(inode, pos >> PAGE_SHIFT, &folio, > > SGP_CACHE); > > + error =3D shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > &folio, SGP_CACHE); >=20 > The "0" here could be (pos + BBTOB(bp->length)) since we're likely > going > to write there soon.=C2=A0 Granted, no current user of xmbufs actually > uses a > blocksize larger than PAGE_SIZE, but in theory we could someday turn > that on. >=20 > Everything below here looks sane enough to me, but I'm not that much > of > an expert on mm/ things outside of the pagecache and shmem.c. ... and here. XFS is no using an SGP flag that allows shmem_get_folio to allocate a page beyond the end of the i_size. --=20 All Rights Reversed.