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 8BE61C4332F for ; Sat, 17 Dec 2022 02:59:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F86F8E0003; Fri, 16 Dec 2022 21:59:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A83A8E0001; Fri, 16 Dec 2022 21:59:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED94C8E0003; Fri, 16 Dec 2022 21:59:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DCBA98E0001 for ; Fri, 16 Dec 2022 21:59:55 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A468F16045E for ; Sat, 17 Dec 2022 02:59:55 +0000 (UTC) X-FDA: 80250293550.17.C3FCAC1 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf10.hostedemail.com (Postfix) with ESMTP id 68578C0005 for ; Sat, 17 Dec 2022 02:59:52 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf10.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671245993; 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; bh=UofI06fuXF4TeBV4X2MhHoIj//B27jeNOi9alpNKnoA=; b=5jWfC278KovVt1jpbI7e5ZJHWHhO2JXxhhYKPkOkrkm87/IRPtNoWVIQj8HCYK1amOXW2z vccz2o4J3XlB/jROaEGZK/gWoCRm4zkMzr1Q20Hx5Fws14lq6rvoIeOSFyS3XJgEQVuDm4 UP2p3MoLjobBJwSpd/R/5Acdsz5RQXk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf10.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671245993; a=rsa-sha256; cv=none; b=0auiSxyis2kgUrKg0p0WZs0QxB+Jrwy/KtincmhnyPWrUNBwpkD8gGyMFJulzxJv/1/6wc MMIbAUG4EsL7uZhfVuCm2Y12R5xohyAQCXW8YKhrBYXgiuUXIc3CdHFK17qWlmqeQZ4C+i 6LJgG3wkwf/dBK6WKFe3dfki797JAAk= Received: from canpemm500002.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4NYrJj334wz16Lg7; Sat, 17 Dec 2022 10:58:45 +0800 (CST) Received: from [10.174.151.185] (10.174.151.185) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 17 Dec 2022 10:59:46 +0800 Subject: Re: [PATCH 2/2] mm: Fix a few rare cases of using swapin error pte marker To: Peter Xu , , CC: Andrea Arcangeli , Pengfei Xu , Nadav Amit , David Hildenbrand , Andrew Morton , Huang Ying References: <20221214200453.1772655-1-peterx@redhat.com> <20221214200453.1772655-3-peterx@redhat.com> From: Miaohe Lin Message-ID: <9669705e-1bee-c789-86c7-6e3f6e28d109@huawei.com> Date: Sat, 17 Dec 2022 10:59:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20221214200453.1772655-3-peterx@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.151.185] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 68578C0005 X-Stat-Signature: 75nyxk7a5wfcw4ct9kgpmizdaao6pug8 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1671245992-690800 X-HE-Meta: U2FsdGVkX193kqGBCFXXjzg1jCxsiVcJhNaxFObzPdu/04eXt1ghBan++8M9Ir+6MQKhDW3He+sJAjalHBLGffjCtKjuHzUgMpekwTuiqS2+ifMnsy5Gmf37Nl8h+0t9N++6rr0xp+Yx3jQZYn8mAw/LCtHo1rjp3rJVB5ktBX6z9QOVQI5lGtbFiW+8Qq5Z5S/FHuouBqbhYgNDSwfw0Tg/hN5r9fuWidBkCtBCR0lsg8MzGswFf5gYsawk7AgqFJrzbrPs0sGTTh2q0fouARkcV7Sq0epCu6yhDWUXaZ9ONnsRaWxbEH8LnV+YzYzC8U51Ib0S2mZJ7VbRGAzlsjPmUNkFK3tCVQGaSEtSLszQLzjrWtkMvCIAXvT1s5IzIF9N78O3QxmjnlNQb7J32GzHzT4m149TqBgviZlttID2n/t42Qw5+6g97ahPQy7V9X+Wf6cH4MhZDpWGNgYakdK1LUQruT6KxCHxJzVC3I9FZXhEEFoARZb/Qr2n2Z337FQNEFaGMhPYU2HHWm8zpZucQwnftLt4hVLRWDtXtERTB7AmeL6mtxU1oER+PVUGdKpB44m5bkoclKUXupgneJvC0Bk1a/KntCJuiDcka5MmWPsVaXvR3vW3Ic0cPihVBfRb0/sqm6oQ0XTHH2aUK2dT/XVAh1LBSoZqQF5xGTpcbcPy/yZUnIvncu5I8BssTlgMCbfoGVgK5gobAGs/zeJGwfWOha+pb/xOtHpjAvGoNqjvGbC8tMLIwhr+lDccOvDh10FiPicEh6sKTWsrC5kMXRG5hc89MMX8CXmtD0Wsw6EX1WG8UVYmR09yEpny5Sb6AvPA+0C/WJ9zoLQro00ODrIlYvlyFAcPiDfaVuNpVZqPHxwIZ7S/Bg+B61fvVOL1Au5OrEo= 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 2022/12/15 4:04, Peter Xu wrote: > 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 Looks good to me. Thanks. Reviewed-by: Miaohe Lin Thanks, Miaohe Lin