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 6511FC7EE26 for ; Wed, 3 May 2023 09:51:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E67336B0071; Wed, 3 May 2023 05:51:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E16FE6B0072; Wed, 3 May 2023 05:51:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D06A66B0074; Wed, 3 May 2023 05:51:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by kanga.kvack.org (Postfix) with ESMTP id AC58F6B0071 for ; Wed, 3 May 2023 05:51:55 -0400 (EDT) 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-out2.suse.de (Postfix) with ESMTPS id C36FF201C0; Wed, 3 May 2023 09:51:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1683107514; h=from:from:reply-to: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=soq0aEXLMxDRlg7n5wnuI4EdxoEl76KWrCbeYIOeHsI=; b=cogHyw3HCR4znCiCaZFJUzlJcAtbsOQx0HyYgq4JVpLr9ki+xhTorjqF179FRy5xlgBMw9 wptMHmGBjCUqS9XMiRouR8UMTiINkMZ4OfiWw+2Hg7nhYgUFrrWyKbFQFmVW7ix07cS3bc Bnf64voPa11LSOy4RVY/PtdQzbNXdEg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1683107514; h=from:from:reply-to: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=soq0aEXLMxDRlg7n5wnuI4EdxoEl76KWrCbeYIOeHsI=; b=lfZG1EpTcipBXXGupOYLnqRyxBri7oj4VBsu7SkDD2s/jaEBSjbATHbBw4zmYbXfUxVNkq j+myvpmvL7u0UsDw== 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 B51621331F; Wed, 3 May 2023 09:51:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id rfctLLouUmTYIQAAMHmgww (envelope-from ); Wed, 03 May 2023 09:51:54 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 45DDCA0744; Wed, 3 May 2023 11:51:54 +0200 (CEST) Date: Wed, 3 May 2023 11:51:54 +0200 From: Jan Kara To: Andrew Morton Cc: Jan Kara , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Lorenzo Stoakes , Christoph Hellwig , David Hildenbrand Subject: Re: [PATCH] mm: Do not reclaim private data from pinned page Message-ID: <20230503095154.syth4jorsdu55ko4@quack3> References: <20230428124140.30166-1-jack@suse.cz> <20230502132020.5a720158307c11d5b8efe1d9@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230502132020.5a720158307c11d5b8efe1d9@linux-foundation.org> 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 Tue 02-05-23 13:20:20, Andrew Morton wrote: > On Fri, 28 Apr 2023 14:41:40 +0200 Jan Kara wrote: > > > If the page is pinned, there's no point in trying to reclaim it. > > Furthermore if the page is from the page cache we don't want to reclaim > > fs-private data from the page because the pinning process may be writing > > to the page at any time and reclaiming fs private info on a dirty page > > can upset the filesystem (see link below). > > Obviously I'll add a cc:stable here. I'm suspecting it's so old that > there's no real Fixes: target that makes sense? In principle the problem is there ever since MM started to track dirty shared pages and filesystems started to use .page_mkwrite callbacks. So for very long, yes. That being said the fix makes sense only since we've added page pinning infrastructure and started using it in various places which is not that long ago (in 2020, first patches in this direction have been merged to 5.7). So we could mark it for stable with 5.7+. > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -1901,6 +1901,16 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > > } > > } > > > > + /* > > + * Folio is unmapped now so it cannot be newly pinned anymore. > > + * No point in trying to reclaim folio if it is pinned. > > + * Furthermore we don't want to reclaim underlying fs metadata > > + * if the folio is pinned and thus potentially modified by the > > + * pinning process as that may upset the filesystem. > > + */ > > + if (folio_maybe_dma_pinned(folio)) > > + goto activate_locked; > > + > > So I expect the -stable maintainers will be looking for a pre-folios > version of this when the time comes. Yeah, right. Luckily that's going to be pretty easy :). Honza -- Jan Kara SUSE Labs, CR