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 36FDBCA100A for ; Fri, 30 Aug 2024 23:21:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 344126B0168; Fri, 30 Aug 2024 19:21:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F3B36B016D; Fri, 30 Aug 2024 19:21:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BCEF6B016B; Fri, 30 Aug 2024 19:21:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E48748D0002 for ; Fri, 30 Aug 2024 19:21:37 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 792BC14073E for ; Fri, 30 Aug 2024 23:21:37 +0000 (UTC) X-FDA: 82510485834.24.C49E1C2 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf01.hostedemail.com (Postfix) with ESMTP id CBDDF40010 for ; Fri, 30 Aug 2024 23:21:34 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XUwKCxWr; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725059974; 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:dkim-signature; bh=XZkbhoz/E9TOyTdw2qKg3ORWIerKremxQbegCghKOZc=; b=NOJPkFjbU2xZmj0BEvPK7m95ZAFB8RpCgxxUtpnCIN7yZkVhvaOsYSkHJ+WyMBPjso9hMU jS1Vwoavw+sMeuu+N5rRY2emVzfrxEv/5s+CwlPUJAplvlTYETmQbMN7Fb24YzXQvwrq/J 64rCPdnVo7aWSeqw6FQ/Uj6esT+8EJc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XUwKCxWr; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725059974; a=rsa-sha256; cv=none; b=18/CrjHnQsQTA3ztAKeHc3YoOs/0X1pu4h19/7xjJ0cgfACF6RE2ppAwwO/AXFkxvGZIMH nMicTOvU3sZ7rXzQ5DEwbTvqNKJNHWS9yVobwJG9heXYHNxEoS2HR+J9bk0kwHGK0Q44gW YSs+IfXGMQ0AvuVr+ep1ZE62XNY31yk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C5CCDA41DA7; Fri, 30 Aug 2024 23:21:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B72BC4CEC2; Fri, 30 Aug 2024 23:21:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725060093; bh=5kQ5XAoyoKFTewRRACml0pmLhqwmlzoDXNmRegMVqYo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XUwKCxWr00OtFL5EyPVrZ+OEr9fAJiP2GLXqwBc44RH3A60QVfmsyvbsbjIzTlpz2 lDg12/LbYrtbM/a/zli50B2dj64iVWMZc5oTOUj+vqtcmiWzC01D2qMHT2BQsl97I4 RRYajFDqySVHC9jU7QDMl1wyuxUryv6lbTCt1HS1j5W0tJIbefOIw+V2rzCp+cg6Un NVDnNk7OknJaSdxONiAkLXvhKmzkZWDjTvk9EtWu+eyqlKVluCtY1OovQOQFLbuVzh 2vgchdbJxMg8DnC/EwG+RPedwfOWELvxm4UFrjt1byj+229QlRNLTfuG2AgC48eTYV k+d8bQrNhZaFQ== Date: Fri, 30 Aug 2024 16:21:32 -0700 From: "Darrick J. Wong" To: Rik van Riel Cc: Hugh Dickins , kernel-team@meta.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner , Vlastimil Babka Subject: Re: [PATCH] mm,tmpfs: consider end of file write in shmem_is_huge Message-ID: <20240830232132.GG6257@frogsfrogsfrogs> References: <20240829235415.57374fc3@imladris.surriel.com> <20240830055244.GD6257@frogsfrogsfrogs> <97ba80061354fef89349a70e1cb8eb34dd7730f3.camel@surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <97ba80061354fef89349a70e1cb8eb34dd7730f3.camel@surriel.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CBDDF40010 X-Stat-Signature: jkmn4bf7pa6r5s1kz68xt6o94npt6epo X-Rspam-User: X-HE-Tag: 1725060094-216472 X-HE-Meta: U2FsdGVkX1+XqLNa73KJwSJj113sC8DPuZ0FWrKTkeiWdo64asPgerqHrSRubp7K7ZFMbMuakzAbqBt730eNfVt99Sd6srJwaqzgCp+fTcV/24WtLehpxEQidshrsWDzwPyKLVFyqA4PrJh0TKBJM+taUL54Dho7wI/5zHdZ4UeWpNrM6RJhY1DSHp7MxJ3dwksNYp5C/S0z8QqeCmSvZj9sXPRjePwPsdVKCOcv9d/R85FrPYasSfTNSCDPugsg42WFB4ghOjhJnjlVGX60b996v6L7cEQjjZh4Mkvl4x/VlknBqDeKq370MMb4kTudTJIBKUlunl49+x+/ssPmad5lIqIsLYTu1Uf5uMWv8ZzY+nAuIXCngPiDPI9rD0Az3XfKLx48/c/JbUo1YgGP3jmgyGTqWlJ5LGb/UMTzkj49IKthQ7FmLyRjf8KGOpndNFu2y1jp3gN8s1E4h5vFyibffCi8Mki47vG9v4Y7+KThXRh1+Pq8JP6f1V+6Q7ZQjsaa8vsXJZdzNMqWaxn2imF29VmPuLEKvH4q7MPpijmo1pzv8ubGf+6u3rWjjyE0Y6bE38QML84v2tvNUh40S0AIMn+yg2GHodMVGgipdglzY7NS3LX1shx60UhcE1mfz0mIgjai+1MbL8c7YdqdMsUpcBeLWnMN8a1oWtO2DsVMJA/Kr5VmV1EMGxzR2aZvwjvO8aaDmhXP76LwXvBPoZAIkhqv+tP24AybbPmmP8BPmea7maD7Ljz8noxhLOc/3bZpr4mqCdwTh5KwqZXi7s4miQcetOQsJUIbcbXfSfDqsUyv/75nBsXy2OALLCk6Pft3J7NRI6AUr8Pt8W6Bo8OMfSNHHH0wSSXycO/SQ0o2JGhXWw8/SyEiZji5co9zxw2dNbXQVyOZCrfuJhIQbZn+yCCza0Xj8Oq+cKQRPnIPlK2kZ4wAisl2AVLiRn4Kb68t5XNdXYSVujTTHmy Ft+ka5Eh r+pBVwqrYmGNmDeJz0ECr65cH+LQccf6ETT+FXVQ+Bfq8KiAOLsDV/tphIn3OiduqyjKyY9nFh6VlqukXJTMMu6bVI9NqdW7Q5XktgPI3YeVhpvMaMzlxEe3I3U1rTRS/OTWIMifxiRUPCifNm94uCiF7D0Y+rvOHlsNJNVnq1qOplHo4QmPD6mMz5rQwLijxU61yPGEpX23+YtTQm4stnNHuwolunfoHxr02RFLw7Pe8NFExgd3IuAq3E7j/YsfyyyGAuwM4ZbXDyi+QFEwYq6MTP8J2JE0HYTPP1GmkiQIjK4tyG52HaUSSfQ7V4Yl9csbv 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 Fri, Aug 30, 2024 at 09:11:32AM -0400, Rik van Riel wrote: > 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: > > > > > > @@ -196,7 +196,7 @@ xfile_store( > > >   unsigned int len; > > >   unsigned int offset; > > >   > > > - if (shmem_get_folio(inode, pos >> PAGE_SHIFT, > > > &folio, > > > + if (shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > > &folio, > > > > 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. > > > > >   SGP_CACHE) < 0) > > With SGP_CACHE, won't shmem_get_folio simply refuse to allocate > any pages beyond the end of the inode? Yes, though we're careful to i_size_write appropriate beforehand such that @index is always within EOF. --D > if (sgp <= SGP_CACHE && > ((loff_t)index << PAGE_SHIFT) >= i_size_read(inode)) > return -EINVAL; > > > >   break; > > >   if (filemap_check_wb_err(inode->i_mapping, 0)) { > > > @@ -267,7 +267,7 @@ xfile_get_folio( > > >   i_size_write(inode, pos + len); > > >   > > >   pflags = memalloc_nofs_save(); > > > - error = shmem_get_folio(inode, pos >> PAGE_SHIFT, &folio, > > > + error = shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > > &folio, > > > > 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. > > > > >   (flags & XFILE_ALLOC) ? SGP_CACHE : > > > SGP_READ); > > The same applies here. > > > >   memalloc_nofs_restore(pflags); > > >   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( > > >   return -ENOMEM; > > >   } > > >   > > > - error = shmem_get_folio(inode, pos >> PAGE_SHIFT, &folio, > > > SGP_CACHE); > > > + error = shmem_get_folio(inode, pos >> PAGE_SHIFT, 0, > > > &folio, SGP_CACHE); > > > > The "0" here could be (pos + BBTOB(bp->length)) since we're likely > > going > > to write there soon.  Granted, no current user of xmbufs actually > > uses a > > blocksize larger than PAGE_SIZE, but in theory we could someday turn > > that on. > > > > 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. > > -- > All Rights Reversed.