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 C2C26C10F1E for ; Fri, 16 Dec 2022 00:07:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B369D8E0003; Thu, 15 Dec 2022 19:07:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE6528E0002; Thu, 15 Dec 2022 19:07:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D4BB8E0003; Thu, 15 Dec 2022 19:07:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 91FBB8E0002 for ; Thu, 15 Dec 2022 19:07:10 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 676F8120117 for ; Fri, 16 Dec 2022 00:07:10 +0000 (UTC) X-FDA: 80246229420.09.BA80A83 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf05.hostedemail.com (Postfix) with ESMTP id 92AB1100017 for ; Fri, 16 Dec 2022 00:07:07 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cJkJGzNa; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671149228; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j9d1UjG5uKSqpY7H2sHmJoFLueLfbURS4bQaY/ODfOA=; b=Js0/SvI6Qm2CXCD9OpFPovFVJ1ycTKHAtyQRZ1SVRHlsoldZINClPPs0y9O/SL40vw7IO8 yxqF0kWaSvedQgXLkjs0xFXapAO2b4HUNKxpQQApyg7CDpr36vKk2EY6WNYaN0WyHH3CYA 5lMQAymAGjknlDhFlaEaOyF5N/ogdrw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cJkJGzNa; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671149228; a=rsa-sha256; cv=none; b=zWBhMFxIiwWkBOFojitZDhZ8ae5PAqpqGvTJNLZL81g2614v6P2qFpim3RmXOrY7PXRouE Ul5syAolGSFEbRHQHzx3Y5d7LORxYkoyvjv9VTL0SNYlPx2WyZUe3zIObhSABcv/7uYdoB yHyxNebrYF4hAlzSuObngmawJs6dlw8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671149227; x=1702685227; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=/z5HDHhx0SlHXpvN/Z4yVFIrDq7f8gnnwyIizEhhHPI=; b=cJkJGzNa2Bm/jYI66/cSoKmALuJ4GmphCwjrm7Vfm2OpVabsfzv9bnh8 WnlV0p6FfBuMqO61pCgi94y1SOav0/4Q/Iof5A0GPZskqW79LMRHldvTB aV2Jg9o3Yg/pcKtnf98EG5qRMrugU9y9zv/X+8VaO7xWdX1nzyNYNdNqL vIe1qqrTj6yCktjsSHI93BI6GkorzT/g2hyu9ThlweFtdCvymevyubHk8 cNANwc44QtQVEj8liNIh770i2jKUfjrt4kdT4sdmw6gniOKkGDZoBFXT3 JqMYlpDOQ1LmAH6J3YiRCHWQ9gz3A32gsw1fTuny453jwFLi+ewqvVaEd Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10562"; a="299179134" X-IronPort-AV: E=Sophos;i="5.96,248,1665471600"; d="scan'208";a="299179134" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2022 16:07:05 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10562"; a="599755703" X-IronPort-AV: E=Sophos;i="5.96,248,1665471600"; d="scan'208";a="599755703" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2022 16:07:02 -0800 From: "Huang, Ying" To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli , Pengfei Xu , Nadav Amit , David Hildenbrand , Andrew Morton , Miaohe Lin Subject: Re: [PATCH 2/2] mm: Fix a few rare cases of using swapin error pte marker In-Reply-To: (Peter Xu's message of "Thu, 15 Dec 2022 09:05:28 -0500") References: <20221214200453.1772655-1-peterx@redhat.com> <20221214200453.1772655-3-peterx@redhat.com> <87bko5cf8y.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Fri, 16 Dec 2022 08:06:13 +0800 Message-ID: <87v8mc9pqi.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 92AB1100017 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 1844uotjhwf7ek9j3qkjxz93nzws8hbh X-HE-Tag: 1671149227-282270 X-HE-Meta: U2FsdGVkX1+QfgPP1Ssl1oNtW1gk2fhG06HpHDj25dOGqZbEsKevFp1raQGGb9oxNL+m8DLT7LuC9iUG/4EHjdyz0H+Cnotz3etd/19e+XCD/1nzzGCFo84fSdna1SJ9SHk3f6M2OUBp55zM0hHFrKPPV7pWYaGp9qTR/MEN1kfpckqypKmEFuqkRnPmmYtck3S/iee5dohjNc/frK93tfwKCCvKL8hDlJf51T3WD0XbuWlJoMQFw/McAQnNqFZ1SJR3cNMcnJ/0ilDr1W+2D5d101JoXA1JF2CQan9CmALiQeZerSwBtwy4ct67qvOZNH9/zroUbAmmkO5dgekKlHm94Ix+TV53zWSu0zIGKKo71OKT5kESiP+npDWA+6s3D/R8R1VzFOVHLPOEqNFcM2CC1v/25i7iW6kxAVGWtt21X3pUvFDliCZyEdlyrgwqnRIzQpj0jgH9o71piGXzvOXSkzSubFoo1pL/p55a1etnl9liiG6t9Hx/+7TE4WkBxqutf/Bqsknc19dHvAO8EWmuZjW4yfNSZWBvqkI7Qw69g+iYEDuqXN5IaNRlT71K/6Am/Yri2t5dy14upuLHEOfoihyJW1wRkWIk/ODpjsa9Im1b1c4eZRJM+E2Q8/ru56abLz/Lgaa96F4Pj8safmGwvCSXKHtgfpo+5Vn/t7upS0B1q7wziuKvJ1FSbI4GFf5A4nS8qQUFAAmJhDxk6rnHTSzl7q8sVxTHrhF/OmkkMKdQqEC3e8RnAVTpsEQc1kP3/vTmvCHRTc5f+QmS1LNC/Gpf5drtNzcxFM4LehDp8eWADFLBI/u9hqk50eg/0uQ5DH3dAOHR8g+E781Y0YXDFATGxf8DRiw0mA+DRECKCr/3WzJeF5oocqNoLi84h7L578u2KjAzC2oIJnkkD3PztAZ9cv4u1T96TWiRItOvVh6dD/BnCw== 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: Peter Xu writes: > On Thu, Dec 15, 2022 at 03:12:13PM +0800, Huang, Ying wrote: >> Peter Xu writes: >> >> > This patch should harden commit 15520a3f0469 ("mm: use pte markers for swap >> > errors") on using pte markers for swapin errors on a few corner cases. >> > >> > 1. Propagate swapin errors across fork()s: if there're swapin errors in >> > the parent mm, after fork()s the child should sigbus too when an error >> > page is accessed. >> > >> > 2. Fix a rare condition race in pte_marker_clear() where a uffd-wp pte >> > marker can be quickly switched to a swapin error. >> > >> > 3. Explicitly ignore swapin error pte markers in change_protection(). >> > >> > I mostly don't worry on (2) or (3) at all, but we should still have them. >> > Case (1) is special because it can potentially cause silent data corrupt on >> > child when parent has swapin error triggered with swapoff, but since swapin >> > error is rare itself already it's probably not easy to trigger either. >> > >> > Currently there is a priority difference between the uffd-wp bit and the >> > swapin error entry, in which the swapin error always has higher >> > priority (e.g. we don't need to wr-protect a swapin error pte marker). >> > >> > If there will be a 3rd bit introduced, we'll probably need to consider a >> > more involved approach so we may need to start operate on the bits. Let's >> > leave that for later. >> > >> > This patch is tested with case (1) explicitly where we'll get corrupted >> > data before in the child if there's existing swapin error pte markers, and >> > after patch applied the child can be rightfully killed. >> > >> > We don't need to copy stable for this one since 15520a3f0469 just landed as >> > part of v6.2-rc1, only "Fixes" applied. >> > >> > Fixes: 15520a3f0469 ("mm: use pte markers for swap errors") >> > Signed-off-by: Peter Xu >> > --- >> > mm/hugetlb.c | 3 +++ >> > mm/memory.c | 8 ++++++-- >> > mm/mprotect.c | 8 +++++++- >> > 3 files changed, 16 insertions(+), 3 deletions(-) >> > >> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> > index f5f445c39dbc..1e8e4eb10328 100644 >> > --- a/mm/hugetlb.c >> > +++ b/mm/hugetlb.c >> > @@ -4884,6 +4884,9 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, >> > entry = huge_pte_clear_uffd_wp(entry); >> > set_huge_pte_at(dst, addr, dst_pte, entry); >> > } else if (unlikely(is_pte_marker(entry))) { >> > + /* No swap on hugetlb */ >> > + WARN_ON_ONCE( >> > + is_swapin_error_entry(pte_to_swp_entry(entry))); >> > /* >> > * We copy the pte marker only if the dst vma has >> > * uffd-wp enabled. >> > diff --git a/mm/memory.c b/mm/memory.c >> > index 032ef700c3e8..3e836fecd035 100644 >> > --- a/mm/memory.c >> > +++ b/mm/memory.c >> > @@ -828,7 +828,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, >> > return -EBUSY; >> > return -ENOENT; >> > } else if (is_pte_marker_entry(entry)) { >> > - if (userfaultfd_wp(dst_vma)) >> > + if (is_swapin_error_entry(entry) || userfaultfd_wp(dst_vma)) >> >> Should we do this in [1/2]? It appears that we introduce an issue in >> [1/2] and fix it in [2/2]? > > Patch 1 copied stable with 5.19+, this one is not. > > So if we want to squash, we may want to squash both patches into one, then > we'll need an explicit follow up on stable branch with something like patch > 1. The current way works easier for stable, but I can also do the other. Got it. Thanks for explanation. It's OK for me to keep them in current way. Best Regards, Huang, Ying