Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3537pxv; Fri, 30 Jul 2021 16:51:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9CXPu2Wxze3gcPtKRIqwWVLYVs/wGIGV5con6NHecxvV8O3izSz6t2KwDjk7QYBKtc6rz X-Received: by 2002:a05:6602:2406:: with SMTP id s6mr3358666ioa.159.1627689090258; Fri, 30 Jul 2021 16:51:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627689090; cv=none; d=google.com; s=arc-20160816; b=mKAySIak1AM5aGiQ0L7otYV6C4xxhYPgZPWjByhO5y6p4TrHPTvh4ldDcUQp3n3FMl e3knDsA78GC6sxUW4M716RE5qbU29OnL/SrYPLFafd2qtglJTSgTEX/K7WSvDBfC+Wqo JRjkSAEqTjFum2/QcC96g35vtupX9K97sMNuvYgoLMpJhwbwGBJCT6Q20RimNSw/GM+5 3EEZ/UeTWjmxi2SuIK7NTPXqVrUZhmMsjXd1ud81uW1RepbmZTeUZWt3aBumMkUCS7+j 1s3kYCw4xTohjb1PrOkVaoqM1xYwdZK+8gIa1N9XG4S4EWyz+dFiLnto5LUpjzIJMQVY TyPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=HYPzEhg0/ZZoBcXr9dsUKJdtTAKeNCNJr4RSfiPRVf4=; b=ndKer0Gxs+mwwiAZVyGko0vhQ0YD16Q1ltefYEaA4I9tN5GaSHAy640DGaxe598tM3 jGk3+IOQTzIX6Tlxf5nMOQzuEp0hcyDfURSA2eNMF3s4jqfztyVEhEyv5EF9yK4gv9PY 9LJgNxfbd4uVN2fiUIXlneJJUDbQ79ia3yr9B2SYLVHcORQEQkXpH7GYc5fHStWPD+KT ZR+6eVjtqhVpmK6Z7saQsRMVLmzyPeQnlZTWXXKOWx+EyCM2ZuAn35DX6Pu/p/Bvpz+t JD4yqG5Nx46YPgncQstDvWHRXNnsZ6P+V9CuTaKueCZety2Vxpm2MXTWmL9MSf8N455y aX1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KjWLVlYd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y14si3828018iot.9.2021.07.30.16.51.10; Fri, 30 Jul 2021 16:51:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KjWLVlYd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234289AbhG3XtK (ORCPT + 99 others); Fri, 30 Jul 2021 19:49:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234312AbhG3XtH (ORCPT ); Fri, 30 Jul 2021 19:49:07 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B5BAC06175F; Fri, 30 Jul 2021 16:49:01 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id hs10so11006597ejc.0; Fri, 30 Jul 2021 16:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HYPzEhg0/ZZoBcXr9dsUKJdtTAKeNCNJr4RSfiPRVf4=; b=KjWLVlYdbMHNyu8daHscO5bjhMTc83ScQQRkQJs51/weY6+MoWT2UXvSdqDCM/s9D1 7sZ2zbFaVw6CuuBPCKR5xaVMVFCe1w03820ESTI3X8yN/6k1Gjvc/0J1asEopf8Us/SX krhGPj0E6Mri/Jszps7QWUjiap5dOdRBytWn5QgyJFsmxGHlR1Bjvzhr/gY8rdwq/thF DCIRDltbAeKacc+wNSRLGkjk6Z2MiSTPOed/arRPuxBLl9Q6BK5MYReJHxB8Q7LBVf5n Sde7ulBRCOf9ZnW7lkyYr7Ms0Okj+9/UOuA2RFGBMopIxg8TGogaLv26b3kBD+TUw5S2 RrGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HYPzEhg0/ZZoBcXr9dsUKJdtTAKeNCNJr4RSfiPRVf4=; b=koFDzdgeJCG6PAVz/caTWFKOCKO3/ieOvNLN1arSR6PL95G99PBVC40QcpTZ05Q0kV 8LVgTSsFXzNMubiX8DMm1e02ucjLGvH9qAmW2doD4x/6vLnSJq568LaZJ7VVC92/1lYG Lyonw9cKFbKXG24EZfbYWwsfgQ2W1bxCSLOrugWcseiXWmnzsfouP689u6i6ndSh6uZO FsdFsx1fpwnj09eulmlqk8jtqkxhzB2hXdAGFLQr3KIsBij4l/7GRV4F4rgiKEH1RPxE 4Hngs0FKjmb+DI0nDDaSxIIVbPZBsQCxWPVsdCDQMANokQRjFmqjxJzb3wwtt9YVccmT z8mQ== X-Gm-Message-State: AOAM531IqZUe18zsEH59oSe3FMzObx/YUqEuumdhCE4kRbVsrvNZ0ttU FEx4DdPsgY5E7CiqjyhSOViTbcE59+t32P7zKGE= X-Received: by 2002:a17:906:1f82:: with SMTP id t2mr5105584ejr.499.1627688939706; Fri, 30 Jul 2021 16:48:59 -0700 (PDT) MIME-Version: 1.0 References: <2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com> In-Reply-To: From: Yang Shi Date: Fri, 30 Jul 2021 16:48:48 -0700 Message-ID: Subject: Re: [PATCH 02/16] huge tmpfs: fix split_huge_page() after FALLOC_FL_KEEP_SIZE To: Hugh Dickins Cc: Andrew Morton , Shakeel Butt , "Kirill A. Shutemov" , Miaohe Lin , Mike Kravetz , Michal Hocko , Rik van Riel , Christoph Hellwig , Matthew Wilcox , "Eric W. Biederman" , Alexey Gladkov , Chris Wilson , Matthew Auld , Linux FS-devel Mailing List , Linux Kernel Mailing List , linux-api@vger.kernel.org, Linux MM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 30, 2021 at 12:28 AM Hugh Dickins wrote: > > A successful shmem_fallocate() guarantees that the extent has been > reserved, even beyond i_size when the FALLOC_FL_KEEP_SIZE flag was used. > But that guarantee is broken by shmem_unused_huge_shrink()'s attempts to > split huge pages and free their excess beyond i_size; and by other uses > of split_huge_page() near i_size. > > It's sad to add a shmem inode field just for this, but I did not find a > better way to keep the guarantee. A flag to say KEEP_SIZE has been used > would be cheaper, but I'm averse to unclearable flags. The fallocend > field is not perfect either (many disjoint ranges might be fallocated), > but good enough; and gains another use later on. > > Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure") > Signed-off-by: Hugh Dickins Reviewed-by: Yang Shi > --- > include/linux/shmem_fs.h | 13 +++++++++++++ > mm/huge_memory.c | 6 ++++-- > mm/shmem.c | 15 ++++++++++++++- > 3 files changed, 31 insertions(+), 3 deletions(-) > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > index 8e775ce517bb..9b7f7ac52351 100644 > --- a/include/linux/shmem_fs.h > +++ b/include/linux/shmem_fs.h > @@ -18,6 +18,7 @@ struct shmem_inode_info { > unsigned long flags; > unsigned long alloced; /* data pages alloced to file */ > unsigned long swapped; /* subtotal assigned to swap */ > + pgoff_t fallocend; /* highest fallocate endindex */ > struct list_head shrinklist; /* shrinkable hpage inodes */ > struct list_head swaplist; /* chain of maybes on swap */ > struct shared_policy policy; /* NUMA memory alloc policy */ > @@ -119,6 +120,18 @@ static inline bool shmem_file(struct file *file) > return shmem_mapping(file->f_mapping); > } > > +/* > + * If fallocate(FALLOC_FL_KEEP_SIZE) has been used, there may be pages > + * beyond i_size's notion of EOF, which fallocate has committed to reserving: > + * which split_huge_page() must therefore not delete. This use of a single > + * "fallocend" per inode errs on the side of not deleting a reservation when > + * in doubt: there are plenty of cases when it preserves unreserved pages. > + */ > +static inline pgoff_t shmem_fallocend(struct inode *inode, pgoff_t eof) > +{ > + return max(eof, SHMEM_I(inode)->fallocend); > +} > + > extern bool shmem_charge(struct inode *inode, long pages); > extern void shmem_uncharge(struct inode *inode, long pages); > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index afff3ac87067..890fb73ac89b 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2454,11 +2454,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, > > for (i = nr - 1; i >= 1; i--) { > __split_huge_page_tail(head, i, lruvec, list); > - /* Some pages can be beyond i_size: drop them from page cache */ > + /* Some pages can be beyond EOF: drop them from page cache */ > if (head[i].index >= end) { > ClearPageDirty(head + i); > __delete_from_page_cache(head + i, NULL); > - if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head)) > + if (shmem_mapping(head->mapping)) > shmem_uncharge(head->mapping->host, 1); > put_page(head + i); > } else if (!PageAnon(page)) { > @@ -2686,6 +2686,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > * head page lock is good enough to serialize the trimming. > */ > end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE); > + if (shmem_mapping(mapping)) > + end = shmem_fallocend(mapping->host, end); > } > > /* > diff --git a/mm/shmem.c b/mm/shmem.c > index 0cd5c9156457..24c9da6b41c2 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -905,6 +905,9 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, loff_t lend, > if (lend == -1) > end = -1; /* unsigned, so actually very big */ > > + if (info->fallocend > start && info->fallocend <= end && !unfalloc) > + info->fallocend = start; > + > pagevec_init(&pvec); > index = start; > while (index < end && find_lock_entries(mapping, index, end - 1, > @@ -2667,7 +2670,7 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, > struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb); > struct shmem_inode_info *info = SHMEM_I(inode); > struct shmem_falloc shmem_falloc; > - pgoff_t start, index, end; > + pgoff_t start, index, end, undo_fallocend; > int error; > > if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) > @@ -2736,6 +2739,15 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, > inode->i_private = &shmem_falloc; > spin_unlock(&inode->i_lock); > > + /* > + * info->fallocend is only relevant when huge pages might be > + * involved: to prevent split_huge_page() freeing fallocated > + * pages when FALLOC_FL_KEEP_SIZE committed beyond i_size. > + */ > + undo_fallocend = info->fallocend; > + if (info->fallocend < end) > + info->fallocend = end; > + > for (index = start; index < end; ) { > struct page *page; > > @@ -2750,6 +2762,7 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, > else > error = shmem_getpage(inode, index, &page, SGP_FALLOC); > if (error) { > + info->fallocend = undo_fallocend; > /* Remove the !PageUptodate pages we added */ > if (index > start) { > shmem_undo_range(inode, > -- > 2.26.2 >