Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1546380pxp; Sun, 6 Mar 2022 18:45:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJxyQndjahuzrJZwLb7ZG+UuyDwX6JZFjgFJmx/awUuvVvoig3mzKD+xKl6aHwhhoinyPyqA X-Received: by 2002:a17:90b:17ca:b0:1bf:6188:cc00 with SMTP id me10-20020a17090b17ca00b001bf6188cc00mr3401927pjb.2.1646621138693; Sun, 06 Mar 2022 18:45:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646621138; cv=none; d=google.com; s=arc-20160816; b=0H7dwdq1rD5VfJGfX8XEyypYllZgkUtQCfSFdPHUU1bhebuoB0xwD83LveShsL7Ma3 4CAWSMCaQCIcnYM84MybzEmrMbcc3RaEg8ZjEvPQAaFUPXRRdl2wpbVCNa7bD/Keexvk w/QkxZ7OJTWQZwkTShaWFwwOC+AIyq4rSK7GL7fHPG8/9jDBtdzIZKSkpPLWWBrMW/Di 2dtY1m2Ttp3Z1UwquCN0d9nTYH5zcz/kHgh1BK065Z62vzLCvmJDjC7cusJPZ4vPo126 hIZ5K4JlrqpGh+bawenZPsC5ySm85JU34xuzBnnJfOPURr2XUxDjNlr2kE53ecFkNzG4 nurA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature:dkim-signature; bh=CkTc2le/evfGv5vHe0ZQiRXPE48AkbJG0QwJl13Rw2Y=; b=PZHTRsk2kOO+80wTNrKldeflE37GRtSpg0oNnFisrpsVqRkZXDs0h8961a0rKL1vhQ bGrdA02nU7ux8EJtukgOrHtyUznXd4kdh9wxxF6qYoYf4plEi6mNKR8Bi7YnHNbEJuxJ y7k/rmnER4I/cxvrjwdi4HflarVdQYZJruc/8zJVUT4wr1LQopwFOyfjyIp3Gxl4Drux Z4TSWykeKVtDf3lq8AfHmQbIvmOJDHeaZCxA28oMo46bryVLH9PPfGvKUOjzsGl75K+8 VVQ3XWWbqdaPcQjPZ4dEqEUiGoVK57+PJ6NRxVXgJ+esRjFmnCO8OPx55kXpRLwj15YQ rWVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=0x9GzTYV; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=quTd+nj+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 202-20020a6300d3000000b003801b9c342fsi3996397pga.596.2022.03.06.18.45.22; Sun, 06 Mar 2022 18:45:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=0x9GzTYV; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=quTd+nj+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234510AbiCFXvj (ORCPT + 99 others); Sun, 6 Mar 2022 18:51:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234498AbiCFXvi (ORCPT ); Sun, 6 Mar 2022 18:51:38 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8166C46B15; Sun, 6 Mar 2022 15:50:45 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 41268210EA; Sun, 6 Mar 2022 23:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1646610644; h=from:from:reply-to: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=CkTc2le/evfGv5vHe0ZQiRXPE48AkbJG0QwJl13Rw2Y=; b=0x9GzTYVU6B6eTpSGIjIrwLqjspGk1OnxYT1wSDwYQpvUwztAIG4Zyi9UHI42hPljXkBd1 6E5m7FaStfMGOhGh/fHUORlzgLNFlaKjRFc/0Y6XWq17cWdjTee/RSanlonsQrrvXidvrZ FxhfdjqfEfWeSkUv5I2qBmXs8q7T5Os= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1646610644; h=from:from:reply-to: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=CkTc2le/evfGv5vHe0ZQiRXPE48AkbJG0QwJl13Rw2Y=; b=quTd+nj+Vl1e+jsG+Vr+LuD6LfjWHxaLH+jyCdY2AR3/r8SbtfbfjAP7C4mU4hHl7RGC3S WUU179AiYs/6SBCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4C9E2134CD; Sun, 6 Mar 2022 23:50:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ozRcAtJIJWI/WgAAMHmgww (envelope-from ); Sun, 06 Mar 2022 23:50:42 +0000 Subject: [PATCH 04/10] MM: reclaim mustn't enter FS for SWP_FS_OPS swap-space From: NeilBrown To: Andrew Morton Cc: Christoph Hellwig , David Howells , linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Mon, 07 Mar 2022 10:49:38 +1100 Message-ID: <164661057805.13454.8260394379594793099.stgit@noble.brown> In-Reply-To: <164661047081.13454.11679636335222534920.stgit@noble.brown> References: <164661047081.13454.11679636335222534920.stgit@noble.brown> User-Agent: StGit/0.23 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If swap-out is using filesystem operations (SWP_FS_OPS), then it is not safe to enter the FS for reclaim. So only down-grade the requirement for swap pages to __GFP_IO after checking that SWP_FS_OPS are not being used. This makes the calculation of "may_enter_fs" slightly more complex, so move it into a separate function. with that done, there is little value in maintaining the bool variable any more. So replace the may_enter_fs variable with a may_enter_fs() function. This removes any risk for the variable becoming out-of-date. Reviewed-by: Christoph Hellwig Signed-off-by: NeilBrown --- mm/swap.h | 8 ++++++++ mm/vmscan.c | 29 ++++++++++++++++++++--------- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/mm/swap.h b/mm/swap.h index f8265bf0ce00..e19f185df5e2 100644 --- a/mm/swap.h +++ b/mm/swap.h @@ -50,6 +50,10 @@ struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t flag, struct page *swapin_readahead(swp_entry_t entry, gfp_t flag, struct vm_fault *vmf); +static inline unsigned int page_swap_flags(struct page *page) +{ + return page_swap_info(page)->flags; +} #else /* CONFIG_SWAP */ static inline int swap_readpage(struct page *page, bool do_poll) { @@ -129,5 +133,9 @@ static inline void clear_shadow_from_swap_cache(int type, unsigned long begin, { } +static inline unsigned int page_swap_flags(struct page *page) +{ + return 0; +} #endif /* CONFIG_SWAP */ #endif /* _MM_SWAP_H */ diff --git a/mm/vmscan.c b/mm/vmscan.c index 8a178400eea9..ffae4ba82eae 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1508,6 +1508,22 @@ static unsigned int demote_page_list(struct list_head *demote_pages, return nr_succeeded; } +static bool may_enter_fs(struct page *page, gfp_t gfp_mask) +{ + if (gfp_mask & __GFP_FS) + return true; + if (!PageSwapCache(page) || !(gfp_mask & __GFP_IO)) + return false; + /* + * We can "enter_fs" for swap-cache with only __GFP_IO + * providing this isn't SWP_FS_OPS. + * ->flags can be updated non-atomicially (scan_swap_map_slots), + * but that will never affect SWP_FS_OPS, so the data_race + * is safe. + */ + return !data_race(page_swap_flags(page) & SWP_FS_OPS); +} + /* * shrink_page_list() returns the number of reclaimed pages */ @@ -1533,7 +1549,7 @@ static unsigned int shrink_page_list(struct list_head *page_list, struct address_space *mapping; struct page *page; enum page_references references = PAGEREF_RECLAIM; - bool dirty, writeback, may_enter_fs; + bool dirty, writeback; unsigned int nr_pages; cond_resched(); @@ -1557,9 +1573,6 @@ static unsigned int shrink_page_list(struct list_head *page_list, if (!sc->may_unmap && page_mapped(page)) goto keep_locked; - may_enter_fs = (sc->gfp_mask & __GFP_FS) || - (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO)); - /* * The number of dirty pages determines if a node is marked * reclaim_congested. kswapd will stall and start writing @@ -1604,7 +1617,7 @@ static unsigned int shrink_page_list(struct list_head *page_list, * not to fs). In this case mark the page for immediate * reclaim and continue scanning. * - * Require may_enter_fs because we would wait on fs, which + * Require may_enter_fs() because we would wait on fs, which * may not have submitted IO yet. And the loop driver might * enter reclaim, and deadlock if it waits on a page for * which it is needed to do the write (loop masks off @@ -1636,7 +1649,7 @@ static unsigned int shrink_page_list(struct list_head *page_list, /* Case 2 above */ } else if (writeback_throttling_sane(sc) || - !PageReclaim(page) || !may_enter_fs) { + !PageReclaim(page) || !may_enter_fs(page, sc->gfp_mask)) { /* * This is slightly racy - end_page_writeback() * might have just cleared PageReclaim, then @@ -1726,8 +1739,6 @@ static unsigned int shrink_page_list(struct list_head *page_list, goto activate_locked_split; } - may_enter_fs = true; - /* Adding to swap updated mapping */ mapping = page_mapping(page); } @@ -1797,7 +1808,7 @@ static unsigned int shrink_page_list(struct list_head *page_list, if (references == PAGEREF_RECLAIM_CLEAN) goto keep_locked; - if (!may_enter_fs) + if (!may_enter_fs(page, sc->gfp_mask)) goto keep_locked; if (!sc->may_writepage) goto keep_locked;