From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36195A95E for ; Tue, 21 Jan 2025 03:20:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737429618; cv=none; b=MyaqBEvOj+qP7OAgUrB3S84/B/oBDO6+xYZBTAybtRLDBy+Mi8s7CChNUClMSeS87DRswODwiZNYV1vJzlGxKGhjxVeCinmyEkNCkU070pAliwiEc10QwOC7QkKfyePT9hUJ08VYYg8aqOYgsrnpimeeIYPJuJG9s/78Sxnhnos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737429618; c=relaxed/simple; bh=29t0q39jik9muwBisaTit08rzImlW+GopguDOgXDaEA=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=FoODsltuQwgxayFH6ocOBL3X8Wof0++ckh0UaAkmUwdvRqH4/FEfyGs8LPYuYjZPgGQsWlw6f9QPlk8A7lsn5EhxxQuDTxe9WyCaEa1acxkPGPIpSN+6edCUGfWchurJ8S+2wCUYJ58rr0jX5tn2w+rm6TQ3mL0IUFanPEFMZc0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4YcXXP0QG1z20pKP; Tue, 21 Jan 2025 11:20:37 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id E10E4140114; Tue, 21 Jan 2025 11:20:11 +0800 (CST) Received: from [10.173.127.72] (10.173.127.72) by kwepemd200019.china.huawei.com (7.221.188.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 21 Jan 2025 11:20:11 +0800 Subject: Re: [PATCH v2 1/3] mm: memory-failure: update ttu flag inside unmap_poisoned_folio To: David Hildenbrand CC: , , , , , , Wupeng Ma References: <20250116061657.227027-1-mawupeng1@huawei.com> <20250116061657.227027-2-mawupeng1@huawei.com> <21674fcc-bd5d-3e32-6e45-f0a16ab93202@huawei.com> <34ccd133-7623-4cd8-aad7-08526a97c472@redhat.com> <80984553-a2b9-46b4-acdc-f7abba3c755f@redhat.com> From: Miaohe Lin Message-ID: Date: Tue, 21 Jan 2025 11:20:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <80984553-a2b9-46b4-acdc-f7abba3c755f@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemd200019.china.huawei.com (7.221.188.193) On 2025/1/20 16:46, David Hildenbrand wrote: > On 20.01.25 08:49, David Hildenbrand wrote: >> >>>>        if (folio_test_hugetlb(folio) && !folio_test_anon(folio)) { >>>>            struct address_space *mapping; >>>>    @@ -1572,7 +1598,7 @@ void unmap_poisoned_folio(struct folio *folio, enum ttu_flags ttu) >>>>            if (!mapping) { >>>>                pr_info("%#lx: could not lock mapping for mapped hugetlb folio\n", >>>>                    folio_pfn(folio)); >>>> -            return; >>>> +            return -EBUSY; >>>>            } >>>>               try_to_unmap(folio, ttu|TTU_RMAP_LOCKED); >>>> @@ -1580,6 +1606,8 @@ void unmap_poisoned_folio(struct folio *folio, enum ttu_flags ttu) >>>>        } else { >>>>            try_to_unmap(folio, ttu); >>>>        } >>>> + >>>> +    return folio_mapped(folio) ? -EBUSY : 0; >>> >>> Do we really need this return value? It's unused in do_migrate_range(). >> >> I suggested it, because the folio_mapped() is nowadays extremely cheap. >> It cleans up hwpoison_user_mappings() quite nicely. > > I'm also wondering, if in do_migrate_range(), we want to pr_warn_ratelimit() in case still mapped after the call. IIUC, we don't really expect this to happen with SYNC set. Do you mean TTU_SYNC? It seems it's not set. There might be a race will hit the proposed pr_warn_ratelimit(): /* Assume folio is isolated for reclaim, so memory_failure failed to handle it at first time. Then it's put back to LRU. */ do_migrate_range folio_test_hwpoison folio_mapped unmap_poisoned_folio pr_warn_ratelimit(folio_mapped) But I might be miss something. And even this race is possible, it should be really hard to hit. Thanks. .