From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (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 2456C1DFFD for ; Wed, 22 Jan 2025 07:39:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737531548; cv=none; b=hAvJhndOmMBYnXyxhT3GuX/NfWPEOyuplUJcP2ufgcgPt5BjKgL2uTFk9r/6hxu+b3EqB+1vPot8hhemW2d1w9QDuy4yiAXXSLRcZqts2s4GCIt3Z7K1QzGJnH32knM2fybFGvbN2VRXFvhWg4dzvBWrqbKw3Hxx4mv1Lp0tYbE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737531548; c=relaxed/simple; bh=7HgaPuSImhUsI96tBSFovRTiV4SrwfkCxjUmqjLzzDg=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=LEESHMXQDP4wWE/099AaSyd9cZtjx46FWnuPa1xOxAlYf8jLUzKmRQ4qOVVvdcZQQpFxeYn9ibfcr8XXLUTibQPRPS5Frj5otdpUIw/RR/lzxTC8QiHquI+bcEvo82+A4abpAPIbKHBHYrC00qcQGEMaEucQ16Skb3PSgWITOHU= 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.187 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.163.174]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4YdG8N18MQzbp2j; Wed, 22 Jan 2025 15:35:48 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id E8AE914010D; Wed, 22 Jan 2025 15:38:57 +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; Wed, 22 Jan 2025 15:38:57 +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> <2fc40750-2ff7-4e73-ba52-c4d9caaa4f4f@redhat.com> From: Miaohe Lin Message-ID: Date: Wed, 22 Jan 2025 15:38:56 +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: <2fc40750-2ff7-4e73-ba52-c4d9caaa4f4f@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemd200019.china.huawei.com (7.221.188.193) On 2025/1/21 15:58, David Hildenbrand wrote: > On 21.01.25 04:20, Miaohe Lin wrote: >> 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. > > With your patch it will be now, which is the right thing to do I think. > >> >> 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. > > Does try_to_unmap() care about isolation? Skimming over the code, I don't think so. I assume once we take the folio lock, races with reclaim are impossible. I think you're right. I missed folio lock in above race. > > In any case, the race is unexpected, so pr_warn_() would be helpful and not harmful. > > Memory offlining code will later simply skip all PageHWPoison() pages, independent of the refcount as it seems. Failing to unmap might not be handled correctly at all ... I think this might be problematic in other regard (e.g., GUP references), but failing to unmap is "obviously" bad I think :) Agree with you. Thanks. .