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 B4696C433FE for ; Tue, 1 Mar 2022 13:22:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7F418D0002; Tue, 1 Mar 2022 08:22:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D2E448D0001; Tue, 1 Mar 2022 08:22:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1E418D0002; Tue, 1 Mar 2022 08:22:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id B3EA28D0001 for ; Tue, 1 Mar 2022 08:22:16 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6DD7B8249980 for ; Tue, 1 Mar 2022 13:22:16 +0000 (UTC) X-FDA: 79195881072.17.CFE61BA Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf05.hostedemail.com (Postfix) with ESMTP id 3BDD0100010 for ; Tue, 1 Mar 2022 13:22:15 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4K7HrG5W8CzKmGs; Tue, 1 Mar 2022 21:18:38 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) 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.2308.21; Tue, 1 Mar 2022 21:22:11 +0800 Subject: Re: [PATCH RFC] mm/memory-failure.c: fix memory failure race with memory offline To: David Hildenbrand CC: , , , , References: <20220226094034.23938-1-linmiaohe@huawei.com> <4307e915-ac24-58bc-23ad-7e94e2b37170@redhat.com> From: Miaohe Lin Message-ID: Date: Tue, 1 Mar 2022 21:22:11 +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: <4307e915-ac24-58bc-23ad-7e94e2b37170@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3BDD0100010 X-Stat-Signature: hdqbjek36kiwwno4qzf8bw4owo8x9yww Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-HE-Tag: 1646140935-68393 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/3/1 17:53, David Hildenbrand wrote: > On 26.02.22 10:40, Miaohe Lin wrote: >> There is a theoretical race window between memory failure and memory >> offline. Think about the below scene: >> >> CPU A CPU B >> memory_failure offline_pages >> mutex_lock(&mf_mutex); >> TestSetPageHWPoison(p) >> start_isolate_page_range >> has_unmovable_pages >> --PageHWPoison is movable >> do { >> scan_movable_pages >> do_migrate_range >> --PageHWPoison isn't migrated >> } >> test_pages_isolated >> --PageHWPoison is isolated >> remove_memory >> access page... bang >> ... > > I think the motivation for the offlining code was to not block memory > hotunplug (especially on ZONE_MOVABLE) just because there is a > HWpoisoned page. But how often does that happen? This should be really race. The memory failure itself shouldn't be common otherwise we have other problems. > > It's all semi-broken either way. Assume you just offlined a memory block > with a hwpoisoned page. The memmap is stale and the information about > hwpoison is lost. You can happily re-online that memory block and use > *all* memory, including previously hwpoisoned memory. Note that this Agree. This is how it works now. But it seems the hwpoisoned memory might can be used again as normal memory after offline+online. > used to be different in the past, when the memmap was initialized when > adding memory, not when onlining that memory. > > > IMHO, we should stop special casing hwpoison. Either fail offlining > completely if we stumble over a hwpoisoned page, or allow offlining only > if the refcount==0 -- just as any other page. > I'm not sure whether this "rare" race condition worth fixing. But the problem is there and we might come across it. Failing offlining completely sounds not that good but it looks hard to reliably detect the "offline-safe" hwpoisoned page. I can't come out a solution... Many thanks for reply and comment. :) >