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 0B2B9C64ED6 for ; Mon, 13 Feb 2023 09:01:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6604A6B0075; Mon, 13 Feb 2023 04:01:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 610846B0078; Mon, 13 Feb 2023 04:01:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B1016B007B; Mon, 13 Feb 2023 04:01:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3A00C6B0075 for ; Mon, 13 Feb 2023 04:01:43 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0D8D9121276 for ; Mon, 13 Feb 2023 09:01:43 +0000 (UTC) X-FDA: 80461675686.06.42126CF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 9E655160018 for ; Mon, 13 Feb 2023 09:01:40 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JVIxgVVs; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676278900; 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=bXJ41y77DLzQTdnZ8caltqbUlHQTGjYtUH+qH6yTvzI=; b=MYRZepjOp22/A/s+YRD1eBH2GtP6XzZoNzGNOStEVCHPJ0CQarr3HKe7vFk2Q16661FXyN s1oEyJatvH/QcrXKndf1/3RCuJwZJtQqA3UOmHDgD/XNrpBv48Uezxz9tWbzPuI1DOGwGo LVAHUUj4y4xcnzYbCdNU8os7xw2HHGw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JVIxgVVs; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676278900; a=rsa-sha256; cv=none; b=6ojnb53w34aFvMDvSt5AJL2pyJjQDyGTSzLIVZsG8V1HVRJTy8ZcO0FgRRJK07bG74YCmy Du5vLNOZKBUrA6rUZ6DNh3AH+g/JrgWrFR5MKWJm21ndIldAAD9jqrpOxQ65RAqtXZIZCI VhHofo5ORtOGhoqfV8kQ4QEfvAw0q0M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676278900; h=from:from: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=bXJ41y77DLzQTdnZ8caltqbUlHQTGjYtUH+qH6yTvzI=; b=JVIxgVVsnuOUjwPu6XQkSdEdK2ukSvvPDPuJ7XOJNgjzY7DGeNISGLcIeDO8cidyLLyzPf 9nOqEyQZ19Afj6E7azcfpp6LxSAUG+ueXvsuxCM+mLlY/Jr/BTbfUCpl7RBgbMjC6iG4m/ UXrzB1bK5ACuk5ZcEc4YF85z03HlJ4c= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-592-nA7E8MudPDucYiFKGONEKA-1; Mon, 13 Feb 2023 04:01:38 -0500 X-MC-Unique: nA7E8MudPDucYiFKGONEKA-1 Received: by mail-wm1-f71.google.com with SMTP id j20-20020a05600c1c1400b003dc5dd44c0cso5833271wms.8 for ; Mon, 13 Feb 2023 01:01:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bXJ41y77DLzQTdnZ8caltqbUlHQTGjYtUH+qH6yTvzI=; b=S74KlTyjibLn5ELqeRF8Im39Hkt3mXslKikRQarD8IeM4D60cTboMn/1sOsFmGPtO0 bYTkuhw2D7XesKNUy2KArq6U1qPPGeK6/CCc8yJYTxcWgue/0DlEVjVZpxzk4klt0pAg PFZbEEHDp1Rr/91jJGkiIHIS4N9qemNRkcm4gMTmU+RdtOv5Zus/5wpeKRXLVQMj+0Mz PVNT3497H4QGm75Fd/jWSfo0nJgHJxlU/ucgJEkxQ6fKFtJlr+YtwMeOgj8zkj4A+7g3 Yv53HM2dvEbIYSHqmtsXa2iE8zR+qyF1hYQqLAq00U3mcT03nL20+Jr/FuAlCue2zVA0 jLbQ== X-Gm-Message-State: AO0yUKX8uFaHNhW5Cfvaaz9evyG3hm3IgI9QH3fDr6bbCLpa+lpduWJE 4Wk9afGO4a5s37Ci9Dg8Pj0qMOVdelo0rd/ep37anrwdJt3ABjQ1WzZqMyvLmYvntdRCDFqlPHa XVH1gUXoOcQw= X-Received: by 2002:a5d:4392:0:b0:2c5:5e9a:57fa with SMTP id i18-20020a5d4392000000b002c55e9a57famr742932wrq.24.1676278897264; Mon, 13 Feb 2023 01:01:37 -0800 (PST) X-Google-Smtp-Source: AK7set9VtyM+sAOgTcH0wT4b+Em90/RexKPCJfzXesUugyTxY8knA758KLy3q0oLiK1S+Hc1W5aLFg== X-Received: by 2002:a5d:4392:0:b0:2c5:5e9a:57fa with SMTP id i18-20020a5d4392000000b002c55e9a57famr742914wrq.24.1676278897013; Mon, 13 Feb 2023 01:01:37 -0800 (PST) Received: from ?IPV6:2003:cb:c705:6d00:5870:9639:1c17:8162? (p200300cbc7056d00587096391c178162.dip0.t-ipconnect.de. [2003:cb:c705:6d00:5870:9639:1c17:8162]) by smtp.gmail.com with ESMTPSA id s11-20020adfdb0b000000b002c3e1e1dcd7sm10016563wri.104.2023.02.13.01.01.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 01:01:36 -0800 (PST) Message-ID: Date: Mon, 13 Feb 2023 10:01:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Jan Kara , linux-fsdevel@vger.kernel.org Cc: linux-block@vger.kernel.org, linux-mm@kvack.org, John Hubbard , David Howells References: <20230209121046.25360-1-jack@suse.cz> <20230209123206.3548-1-jack@suse.cz> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/5] mm: Do not reclaim private data from pinned page In-Reply-To: <20230209123206.3548-1-jack@suse.cz> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9E655160018 X-Stat-Signature: 88g8tsmk8esz1cjnh34eb34qr1hwexs3 X-HE-Tag: 1676278900-641003 X-HE-Meta: U2FsdGVkX1/+2VwP2ExE+TDzz5pxU83RPGNSaZOWz6vi2HejxSmM1t48SXMgsGsGdXJdZtcUNac1Tn1WiVuEiHcVFXl24//KScCrD8sAlLeXzlRGni7lGxDGsa0dRddepZe8wiHretTwGM13b0zKu3BQ2kWMYJseeEncK+74wNzCKFLeur9/ZKW/4M1S/jLmREEim+VpB58V/6ZcRbUxZR1Fwf51M7BiOFbPd7GTFBsdKa7PoHjE2Ld12LZedpc2Cl38pFFppufC15m/x89c2+e1EM53xZF49bZZqSvJOnslSe8zikysQsGk2keU6CWdpClYZQybBastGLEpMN5UTBq20DWCaDPqHR84FJM9uLKTkFja6VmqBvG2Cg+uihVwX1jAPveqmqzjtSLRcECenP1TLB5V6pwLI+ztEbUAQy7JjhA4wUrocZ6ux1y3I+gMgGyu2rBSjDA40R0AIej6Yp1R05pgp8PuQySg6hUYo7ML7QLP2sn0jn2gv0ekx4luDcqA2cpnfKt4G9+ZQrJHfQ0o0RPc0JSd+BAw6H9knp8+2vW+PDmFD6KiXYQ0xg2n1KRBmdE4IbNt9oGATlqkBZ1q/Ed278FFWUvk0uXkkLdJOxeR24G9nuZVPyeaBmeMeSvvlXVNxX/8/XgyTWwOxrUAVPaIZ9LcltL+RzewR31M0FD0CbUaY9WbRLU3QaHX8XjjZAZVxL5q/T6U9dt6WG+z+O6VPDOKb/qijEveCcJn0tif1g1nX0w+MjTwHEPqe/jyK+h2clIi69S3uQ1zi58OFZREtpS+cc8xHxr05CQ9fDJXbK1EfdPcfFUk2VvvY6L224FCGx4Fry0yEk89InL0ZYbP4P20/8EjeUdV07xV4mPLcW3Egj3Ajmf6lEGmMg5Y01PXKiRNXsqEeG6cOeLQktoW1AQeBx35n1JSPZxJIPkmXuMN0jF0wNuqubbxIxCTm4eMhfqKywks6Sy dRwqBvja 3YRfKNSGKtoH2VkM/8ZrAVLhofTVkRUoMfqZ4eetrGtMBEavWDqB67xCuAiT4S5VLFiwNFuoUudWY9mMsdQKDIsRFKXqqv0G0W+MIl+CdxjiriTmeVKzNUFRWQenwGCSV0f8rD45RJKemalER4xlKgsUO0kbpEgJ7qd0lizTmOvffJU0+cQUBMdhCy0dJ3yg8LQ126xne2yBdUmdT5cZL5D8le9Kg35Qw57pxpaZr1gigCWGg6XmIANhvvvcztanuwrOg7Zm4G6BcxeRJrxktw7SEEbwSjOXef7XOqdyR00MdoxjzAClv7O0XaOhQCSyAEkIRfFJ3/9tbYVUztrISQ7XR0qDBlEIMx6VPSXxXU6tNpP5LLtJzDDkzUQ9pLFrhPav6lXNMa8poJdgGt0mg5YSBIyhryHvowIlNeq+cNAfTK1KpMKuGFlMSocI5p1ncf0FuwpP4NKknUqk= 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 09.02.23 13:31, 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). > > Link: https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz > Signed-off-by: Jan Kara > --- > mm/vmscan.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index bf3eedf0209c..ab3911a8b116 100644 > --- 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 is that may upset the filesystem. > + */ > + if (folio_maybe_dma_pinned(folio)) > + goto activate_locked; > + > mapping = folio_mapping(folio); > if (folio_test_dirty(folio)) { > /* At this point, we made sure that the folio is completely unmapped. However, we specify "TTU_BATCH_FLUSH", so rmap code might defer a TLB flush and consequently defer an IPI sync. I remember that this check here is fine regarding GUP-fast: even if concurrent GUP-fast pins the page after our check here, it should observe the changed PTE and unpin it again. Checking after unmapping makes sense: we reduce the likelyhood of false positives when a file-backed page is mapped many times (>= 1024). OTOH, we might unmap pinned pages because we cannot really detect it early. For anon pages, we have an early (racy) check, which turned out "ok" in practice, because we don't frequently have that many anon pages that are shared by that many processes. I assume we don't want something similar for pagecache pages, because having a single page mapped by many processes can happen easily and would prevent reclaim. I once had a patch lying around that documented for the existing folio_maybe_dma_pinned() for anon pages exactly that (racy+false positives with many mappings). Long story short, I assume this change is fine. -- Thanks, David / dhildenb