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 9941DC4332F for ; Thu, 15 Dec 2022 14:05:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BE8E8E0005; Thu, 15 Dec 2022 09:05:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 047CE8E0002; Thu, 15 Dec 2022 09:05:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2AE28E0005; Thu, 15 Dec 2022 09:05:39 -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 CE6158E0002 for ; Thu, 15 Dec 2022 09:05:39 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 99721120EA4 for ; Thu, 15 Dec 2022 14:05:39 +0000 (UTC) X-FDA: 80244713598.18.BE79648 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id EB9C110003C for ; Thu, 15 Dec 2022 14:05:35 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Q9ZDPLFC; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671113136; 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=f5mWqAZ4oKzRB/AUy0EFC6zsdw46PWyd5mKsEYBuVQc=; b=Wb7E8cmenbRTRBJzF/vsT3PF/k6Ag693263tmQh6Dlo13irFWCmY1ophSB94Dij8354mnt vH+m39ozaBTJNB6vzJiO1csmr2A4FJ4tH+aHr1bZ05kizt1dd6Umnak7j7qfwt54i01V/p xgue1BG8F3aiSWOy3ac45S3jezveT84= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Q9ZDPLFC; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671113136; a=rsa-sha256; cv=none; b=UNynUxyKLwNg3vEs8AldGNZ96ZEbtwYXK81CXsgXxbpWIg3JEgkjcBakfRDcfiSCtG3K3v qd23hHKYhXrWUBA6g++COK94lkTQflob2rv7jnLHC9ULTgV7z9Ec1Iq7zE3uQXe/HrwHe4 CpHDS+SaglIxCS2SGjSw6tLwb5m0jiw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671113135; 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=f5mWqAZ4oKzRB/AUy0EFC6zsdw46PWyd5mKsEYBuVQc=; b=Q9ZDPLFCWMyXWKqRdc7dyDN9nwG2LFnwzydXFMpjs7Zd4P0psF174wq73jhztLT0K8+xWC QhxHvkLC4WHb9GZtSVt05h58z97aej44CFvbiGJf4oJmtiSum335G7NKgPUKKh3mkSFJCM 757KGw2S9BClQhBKZmM2ymaKGAxcNKk= Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-57-Ab58kyfQMHuSnvv-sezCsQ-1; Thu, 15 Dec 2022 09:05:32 -0500 X-MC-Unique: Ab58kyfQMHuSnvv-sezCsQ-1 Received: by mail-oo1-f71.google.com with SMTP id j2-20020a4a7502000000b0049bdd099de9so8121540ooc.0 for ; Thu, 15 Dec 2022 06:05:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=f5mWqAZ4oKzRB/AUy0EFC6zsdw46PWyd5mKsEYBuVQc=; b=FpWU3e7O/PsgAa4pkbv5KBdl0dyZGriFturyuc8saqK4s69bJaPssR8Y3vdGWUpGiB 89qGeAXvjlV8N/8HHgsxDm817hJ8PARWjk88MXVhhkuUWBmYhlN9DHo4+pSDk9NXrlTJ bjkF8PVvFOKsVzAW9CfZnZtPIswpz0jBuPYnCHsYWKtuPtM1HyfDceol7WBgDx6Ne01T 0JYE+gyPffi9ze2cy3gx6hj+FcQc48g0RmCYC1tPSmL8F9b47JAVHIvMocfORBst1fcB 3zWruiEhojoVrzUeVrWUEY/d34RPQjBzy61AXQUfe/571a5418Hxam9VQub6xLD1vlXx JTag== X-Gm-Message-State: AFqh2kpeelzurJy3t705+ARhQ/OAtNQaifT1071gyyTa4b2BSNL/y2Xo NRQI/W+JG80HiJv5IzVz6AgKrfIfmJUw602JfQ75OS+ZKnahTcW8Tn5O2MJRLdXjdwYAalSBaQ3 ILoJfjv+2yj0= X-Received: by 2002:a05:6358:ee96:b0:e2:8961:31eb with SMTP id il22-20020a056358ee9600b000e2896131ebmr360091rwb.18.1671113131160; Thu, 15 Dec 2022 06:05:31 -0800 (PST) X-Google-Smtp-Source: AMrXdXvONXi/dqYJVFx4n5Wjg35lK85YO/Ff/VaOFj8YDa8i+fVvbU4Ufo7cLZgI/t2BoMFIue5OPQ== X-Received: by 2002:a05:6358:ee96:b0:e2:8961:31eb with SMTP id il22-20020a056358ee9600b000e2896131ebmr360055rwb.18.1671113130807; Thu, 15 Dec 2022 06:05:30 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-45-70-31-26-132.dsl.bell.ca. [70.31.26.132]) by smtp.gmail.com with ESMTPSA id y18-20020a37f612000000b006fa2cc1b0fbsm11948112qkj.11.2022.12.15.06.05.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 06:05:30 -0800 (PST) Date: Thu, 15 Dec 2022 09:05:28 -0500 From: Peter Xu To: "Huang, Ying" 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 Message-ID: References: <20221214200453.1772655-1-peterx@redhat.com> <20221214200453.1772655-3-peterx@redhat.com> <87bko5cf8y.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <87bko5cf8y.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: EB9C110003C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: swb593qoesawqddtqhubwhzdcghsjg3a X-HE-Tag: 1671113135-632684 X-HE-Meta: U2FsdGVkX1/nh+KWva5b5b7ysJ4iCM7MCkF95pumr2UtcCJgRODYtJ5uVYW8YMLUiAI0Vck4AkLIWvEyqx5vceQjvDoNA2PWwTpxx2hxYCoFU27KPhy84pWvXXYQNg13zMrPNaxoIGe9ex5ovI3x21dtCeeYJQak/eMAEPH3ip6YVFlAyOiVz+FgzBlXf9/bKcKwC4y6NNs2my6qFbh8C0H6B8vGeR3LD0wNTG7AfkcYki1fJYSkw0E+lbqi97lZRDg7PifSmqeahsehIxwTOhpYYPqJT6sfLTCBgP9dZuClA/4Dhmm+iwchjtOkL4BGSTJyaBcTd9rnseLoaC8F95U15DcapLtN0XvX2FK5YIoBBkqaFsbWN6oRQusY8VDElw6TWNKyBj7o4Z96+UTQFQ6z2Fm7wmGQ1+LIWlak7GA2tgTFIet3bJDBanZU/CHxhOXdFTAr0Moe3/X+TghS9nHmq7HDnbHjBaG4Rt+pElyoylCB7Wp2VWxl812xpqLBwtuHTc3LP1zap78U87CDD1toJo0YfMyqBq9vZTGuiWZf9A4Te90xpMOc9useQR4qRRgnsNhDsVLNaUJVhHBJIB9qA/BydZK+jKUdCzmxNT9f0AP4ugtervvT4ek2EbGSiFxHcuVzWtFMerZCFYEbEhVul69BKqTXhboBxliWVYLXqyb63r+/WVBhWbOwlajlMsUZwpOFBDCrOhFOk9r9y+hRJEysp3WOEsvSZ4mU+W5W7+kCvKqo6rRarPUGBAOpr9q6MxwuUYsr+X/SYBx5lYz41m40yZOF/Z5EXiX/lq0bhSBH9vpjkyqO8iZKBcJ64E63uzmzu14eCKQQL3LWq8CG0QvCnaazSRpje+gQzY50HMoy2f6jfZDmO8UmRtCpYntudSfjUzv+1QlaZTKs8W4qG8mvFiEjJMAd5z5S3ZU+gh96gVmv+OKgp4/hK2lSiwBjJK6d3w00l7diBLg 9tfpPk+9 eNr/dEzYBzbmj5ZYZm8YRiAoo/LytWDjuPebZgIQVDEOsFv/Xd41313XlfHeaDuhhcRkyuAImRXEYJzTGDCeJhyP/axpl/v1iDW+3hA0cafgzQ+wxjmtnsIKyyJP3YY0ZDamm84cvMtEvuK8nYIq9VJ8bniiZwYySj9/EGI5DhSLJnm9ZK4zkwSp9kw== 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 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. Thanks, -- Peter Xu