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 BFA93C433F5 for ; Tue, 1 Mar 2022 09:53:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 545BE8D0002; Tue, 1 Mar 2022 04:53:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F5718D0001; Tue, 1 Mar 2022 04:53:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BBBA8D0002; Tue, 1 Mar 2022 04:53:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 2A35C8D0001 for ; Tue, 1 Mar 2022 04:53:30 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CACF99CD49 for ; Tue, 1 Mar 2022 09:53:29 +0000 (UTC) X-FDA: 79195354938.26.00100E3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 221E9A0002 for ; Tue, 1 Mar 2022 09:53:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646128408; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o4oRUxyIudwvhVVrS54YaQp6VJMJXHr3tnh94n7twRo=; b=N3Yk1BbWQfpO1ZOECgCEmlMln8g/GnbwEbn8bdXmWNuHZ9Efh2Yk7cwE81HrkGw64aSRlL xkxLcujnoHFP9UQAknXJu+gc1cIpAOjxB5G9qkoG1+ZJHKdTL+HypTNQ/YvV11du0NxhX1 q6bIfblef6+4gil9E6UoxKxnKXJVHAM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-462-WlcXrrY7PPugnz73mhrIVg-1; Tue, 01 Mar 2022 04:53:27 -0500 X-MC-Unique: WlcXrrY7PPugnz73mhrIVg-1 Received: by mail-wm1-f69.google.com with SMTP id c62-20020a1c3541000000b003815245c642so745458wma.6 for ; Tue, 01 Mar 2022 01:53:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=o4oRUxyIudwvhVVrS54YaQp6VJMJXHr3tnh94n7twRo=; b=W+4eiPv6B8f3zwokg5skZzhwoae3avhNgotTPFcrOZ1NcgMeM3BpPyVM2LuvJJLN4S S9M37eorRoJ4brd1hw3CHVSF1Z9TotSZyW771RGN8Fp97ENr2oSpCJ2RfFrj1h41BgF+ d6Gn32sSVFhyxMVvDMce5ftzrETScDHdNXyGQlzcqeBaLhx71cjql1J7nnwPRNR6/pPr udkeEP5NeabOdre2qF90z6Ao9KkOVa5Et7Ha7aVDeGGuJJfc9V58jpZk27vlia3fnU7B isON6qqRmeBjS7Q3Dvo3pKnw1+bnoZs9eKksFfgXW2Nt8vu4akpHaMFrTNoU5NMr8GXH 1DKg== X-Gm-Message-State: AOAM5314nBAF+k5Tit6MoZErcnOcW1BtVEIRSFmHEEJ6X7s5B9bvj46b 1aZRA1NuMf1r98k2Sl+RvQb+P1v8zK0iTGnB8qaconcaPqUiVSq/kBz3lRuAz4kIL0gC3c/Otsb ev02GZtAUf7E= X-Received: by 2002:adf:eb11:0:b0:1ef:ca9b:7bd9 with SMTP id s17-20020adfeb11000000b001efca9b7bd9mr7128682wrn.125.1646128406486; Tue, 01 Mar 2022 01:53:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJzi4JCao71n6SvZQPj7T+De0HoitkMQverTg8yxnxgSWl7qGbndd3ReprpyccF7QVyCtMYWvA== X-Received: by 2002:adf:eb11:0:b0:1ef:ca9b:7bd9 with SMTP id s17-20020adfeb11000000b001efca9b7bd9mr7128677wrn.125.1646128406274; Tue, 01 Mar 2022 01:53:26 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:20af:34be:985b:b6c8? ([2a09:80c0:192:0:20af:34be:985b:b6c8]) by smtp.gmail.com with ESMTPSA id c12-20020a05600c0a4c00b00381141f4967sm2821572wmq.35.2022.03.01.01.53.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 01:53:25 -0800 (PST) Message-ID: <4307e915-ac24-58bc-23ad-7e94e2b37170@redhat.com> Date: Tue, 1 Mar 2022 10:53:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH RFC] mm/memory-failure.c: fix memory failure race with memory offline To: Miaohe Lin , akpm@linux-foundation.org, naoya.horiguchi@nec.com, osalvador@suse.de Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220226094034.23938-1-linmiaohe@huawei.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220226094034.23938-1-linmiaohe@huawei.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 221E9A0002 X-Stat-Signature: tjpscukssdr97xg9bb56umj99nuwztkx Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=N3Yk1BbW; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf25.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1646128409-125383 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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? 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 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. -- Thanks, David / dhildenb