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 976E1C433F5 for ; Tue, 19 Apr 2022 21:36:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 165776B0072; Tue, 19 Apr 2022 17:36:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EE026B0073; Tue, 19 Apr 2022 17:36:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA8A36B0074; Tue, 19 Apr 2022 17:36:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id D3F916B0072 for ; Tue, 19 Apr 2022 17:36:45 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A7EE622449 for ; Tue, 19 Apr 2022 21:36:45 +0000 (UTC) X-FDA: 79374938370.16.0DD6BDF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf26.hostedemail.com (Postfix) with ESMTP id CAF5B14000B for ; Tue, 19 Apr 2022 21:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650404204; 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: in-reply-to:in-reply-to:references:references; bh=7TfXXcPBTI9gEOwkVwIJTJGbA/Hn8mIwtWpdMHNWSdc=; b=gp5ydFinNXbAOC9c54ceZ30jOxqODfDWZ9ZntxyoHJFtSRZ5VaCCE0PFJ7k+jVpI9+n4U4 U+6Mkt2sVOJ88JvfrimeBELSttj0aCSPljy70ojW7suJgTeP1l9VgAEjfAD7azBqmBu+v5 PYoRhadA4THLjHX0L5Kz9nj+IT9mRk4= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-259-WEOtdkbbNdipFU-yZFQUmw-1; Tue, 19 Apr 2022 17:36:41 -0400 X-MC-Unique: WEOtdkbbNdipFU-yZFQUmw-1 Received: by mail-il1-f198.google.com with SMTP id x1-20020a056e020f0100b002c98fce9c13so10289577ilj.3 for ; Tue, 19 Apr 2022 14:36:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=y1OMUarmNaiBCBgO4xStYD+V6CFsC/z3nX/OYUoRozY=; b=pP/S7VIUfJnB5qw8+guOVTSwGMS1spks2glnSdolP9xAOfaBjkcGsWaQQKDgMD/Qno 5/5oVn4Nq1SCnzJSXCWRCMYITs7FkdDWUKf1oV7AOcCeXAd852jXesI7/SpvLMop7yVw G1vlP1aSJeMUNBPrypyWcPYLCxotMyoPKETIh23VYCGGxhtmDhtORO6iG0R0xbJWB8er h7sCciJFSUIHhnytqrBAbMl2RrR2LaA1WMYxSHhgzkeP8fLwcfB6bN4z1degrybylFnk ueLMaWAzZx8SGnOXS1VC2RXwvZhePjoFc3bhdiQpkdFUzAK775CQuD0zcHpp9rQxzNaz yv2w== X-Gm-Message-State: AOAM532gaAO8EF3C2tkN86iVsAHmFdDSuFJGZrsSqHqr9xUKjGnpPaML ej6QKjPLY+N4PppVGZdQe0pfbnmFye8sNGqp4NgYRTYAKj5jjaXbfcmN9MaaTkMgvshzPDHsIEY z8BmMIfWnB/o= X-Received: by 2002:a02:b899:0:b0:328:522b:9417 with SMTP id p25-20020a02b899000000b00328522b9417mr8939521jam.79.1650404200733; Tue, 19 Apr 2022 14:36:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxH5Y/aPGi4NZ84/m6rGW0w2H8bGBJbiRYCkyQ8jM+/YBa52IUoO3Lxx0cgJYIQuN5XCExYxg== X-Received: by 2002:a02:b899:0:b0:328:522b:9417 with SMTP id p25-20020a02b899000000b00328522b9417mr8939512jam.79.1650404200532; Tue, 19 Apr 2022 14:36:40 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id p11-20020a056e0206cb00b002cc23fe596esm4292296ils.21.2022.04.19.14.36.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 14:36:39 -0700 (PDT) Date: Tue, 19 Apr 2022 17:36:38 -0400 From: Peter Xu To: Miaohe Lin Cc: akpm@linux-foundation.org, willy@infradead.org, vbabka@suse.cz, dhowells@redhat.com, neilb@suse.de, david@redhat.com, apopple@nvidia.com, surenb@google.com, minchan@kernel.org, sfr@canb.auug.org.au, rcampbell@nvidia.com, naoya.horiguchi@nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/swapfile: unuse_pte can map random data if swap read fails Message-ID: References: <20220416030549.60559-1-linmiaohe@huawei.com> MIME-Version: 1.0 In-Reply-To: <20220416030549.60559-1-linmiaohe@huawei.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="4l5E6+oouBxra33V" Content-Disposition: inline X-Stat-Signature: fjb1zmgnduqop8n9awzktho4ybjaouf1 X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gp5ydFin; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CAF5B14000B X-HE-Tag: 1650404203-102402 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: --4l5E6+oouBxra33V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sat, Apr 16, 2022 at 11:05:49AM +0800, Miaohe Lin wrote: > @@ -1797,6 +1797,17 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, > goto out; > } > > + if (unlikely(!PageUptodate(page))) { > + pte_t pteval; > + > + dec_mm_counter(vma->vm_mm, MM_SWAPENTS); > + pteval = swp_entry_to_pte(make_swapin_error_entry(page)); > + set_pte_at(vma->vm_mm, addr, pte, pteval); > + swap_free(entry); > + ret = 0; > + goto out; > + } > + > /* See do_swap_page() */ > BUG_ON(!PageAnon(page) && PageMappedToDisk(page)); > BUG_ON(PageAnon(page) && PageAnonExclusive(page)); Totally off-topic, but.. today when I was looking at the unuse path I just found that the swp bits could have got lost for either soft-dirty and uffd-wp here? A quick patch attached. Maybe at some point we should start to have some special helpers for set_pte_at() when we're converting between present/non-present ptes, so as to make sure all these will always be taken care of properly. -- Peter Xu --4l5E6+oouBxra33V Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="0001-mm-swap-Fix-lost-swap-bits-in-unuse_pte.patch" >From 60ba535f73f7a7aeab2275d370bf8291cf53755e Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Tue, 19 Apr 2022 17:28:34 -0400 Subject: [PATCH] mm/swap: Fix lost swap bits in unuse_pte() Content-type: text/plain This is observed by code review only but not any real report. When we turn off swapping we could have lost the bits stored in the swap ptes. The new rmap-exclusive bit is fine since that turned into a page flag, but not for soft-dirty and uffd-wp. Add them. Signed-off-by: Peter Xu --- mm/swapfile.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 9398e915b36b..eaea7a1f000b 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1783,7 +1783,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, { struct page *swapcache; spinlock_t *ptl; - pte_t *pte; + pte_t *pte, newpte; int ret = 1; swapcache = page; @@ -1821,8 +1821,12 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, page_add_new_anon_rmap(page, vma, addr); lru_cache_add_inactive_or_unevictable(page, vma); } - set_pte_at(vma->vm_mm, addr, pte, - pte_mkold(mk_pte(page, vma->vm_page_prot))); + new_pte = pte_mkold(mk_pte(page, vma->vm_page_prot)); + if (pte_swp_soft_dirty(*pte)) + pte = pte_mksoft_dirty(new_pte); + if (pte_swp_uffd_wp(*pte)) + pte = pte_mkuffd_wp(new_pte); + set_pte_at(vma->vm_mm, addr, pte, new_pte); swap_free(entry); out: pte_unmap_unlock(pte, ptl); -- 2.32.0 --4l5E6+oouBxra33V--