From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (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 CF7883C8C77 for ; Wed, 20 May 2026 11:24:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779276276; cv=none; b=XdXTQtzNT3qGfAmXzlCbNoQApDhDVVGV6Ugk2Hrrrerhh8HfPdoPQPe67gir1pBHMAMoyf7R7RyESbmPFEaAC0QOpU3HLxhu0BVXCRZXCWABk7ZKctvnQbVxAKLoa47wymEt0w3mOvBhSydRbVNbRyHnRfvDAEvvi5F0ggJuuhM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779276276; c=relaxed/simple; bh=UHCKMZsdQ0UTWBq07EGAbLgGafXi104c938SyBKhagI=; h=Message-ID:Date:MIME-Version:CC:Subject:To:References:From: In-Reply-To:Content-Type; b=bJA/1GEbZFGljNBrlSKErdkKc9CZnw2S8488B0L9OdHMO6SKu4o1n0Zp9D+rH3ofp3TWRZCXS13JLlgqm+rKrjyxGAojCFB5gtcpCvqtgcN45sjbm6/Gc5lhxvemHXyBFuerAPWVvOP0e329/pMRCpv3zeWUToft8EcDN7zRP88= 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; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=VcRZLygb; arc=none smtp.client-ip=113.46.200.220 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="VcRZLygb" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=uX2NCnOWaG1eWrQ7d3fMoAhNcynHoN+Nh013XLu1TqM=; b=VcRZLygbY8zULWBa0AKd7nI9xoWEJP0J91DuhiyLj/4hwB2sKzIxa3r8bpwxYxpw/53OQVXFw K2/eXJJSqhvy6WcPoX+L5XlZ1YKOg+KUMlsLGuJYwfF4BYcecx/jH2HM0aekPdm0ab2XJhshnXX 9Z27G38owT/ItD+e+lHUg9c= Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gL8CD5Yzxz12LDy; Wed, 20 May 2026 19:17:28 +0800 (CST) Received: from kwepemj100016.china.huawei.com (unknown [7.202.194.10]) by mail.maildlp.com (Postfix) with ESMTPS id DDF032025F; Wed, 20 May 2026 19:24:29 +0800 (CST) Received: from [10.174.177.15] (10.174.177.15) by kwepemj100016.china.huawei.com (7.202.194.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Wed, 20 May 2026 19:24:28 +0800 Message-ID: <4ffe8dd7-86b6-42aa-a979-a9ae941e068e@huawei.com> Date: Wed, 20 May 2026 19:24:28 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird CC: , , , , , , , , , , , , , , , Subject: Re: [PATCH v3] mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison To: References: <20260520020128.3506168-1-mawupeng1@huawei.com> From: mawupeng In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemj100016.china.huawei.com (7.202.194.10) On 周三 2026-5-20 16:13, Oscar Salvador (SUSE) wrote: > On Wed, May 20, 2026 at 10:01:28AM +0800, Wupeng Ma wrote: >> madvise(MADV_HWPOISON) can trigger a recursive spinlock self-deadlock >> (AA deadlock) on hugetlb_lock due to a race with concurrent folio >> unmapping. The race scenario: >> >> Thread 1 (madvise MADV_HWPOISON) Thread 2 (unmap) >> ------------------------------- ----------------- >> madvise_inject_error() >> get_user_pages_fast() <- refcount++ >> memory_failure(MF_COUNT_INCREASED) >> get_huge_page_for_hwpoison() >> spin_lock_irq(&hugetlb_lock) >> // refcount == 2 (gup + map) >> // MF_COUNT_INCREASED path: >> count_increased = true >> zap_pte_range() >> page_remove_rmap() >> put_page() <- drops map ref >> // refcount: 2 -> 1 > > Ok, bear with me. > I am not saying the change itself is wrong (maybe it is not), but how we ended > up in zap_pte_range() for a hugetlb folio? > The stacktrace does not seem to have much sense? You are correct. The refcount dropping logic in the `unmap` path was indeed flawed. This issue was originally uncovered by fuzzing. Based on the initial stack trace, we diagnosed it as a recursive locking (AA) deadlock on `hugetlb_lock`. We initially suspected that `unmap` had prematurely released the folio reference count, triggering the free path. However, after a thorough analysis of the refcount state machine and the actual execution context, we confirmed that this hypothesis is impossible. The root cause lies elsewhere in the locking hierarchy, and we are currently tracing the exact call path that leads to the nested `hugetlb_lock` acquisition. The deadlock can be triggered by injecting hardware poison errors on a hugetlb page while concurrent unmapping activity occurs. The following minimal userspace test case demonstrates the race condition by spawning multiple processes to widen the timing window for the lock contention. /* * Repro: hugetlb_lock AA deadlock via consecutive MADV_HWPOISON */ main(): // 1. Map hugetlb page mmap(0x20000000, 0xa000, PROT_READ|PROT_EXEC, MAP_LOCKED|MAP_HUGETLB|MAP_FIXED, -1, 0) // 2. Inject hwpoison twice on same page madvise(0x20000000, 0x4000, MADV_HWPOISON) madvise(0x20000000, 0x4000, MADV_HWPOISON) // 3. Repeat in a fork loop to widen race window Here is the detailed AA deadlock stack with lockdep enabled ============================================ WARNING: possible recursive locking detected 7.0.0-g0eba4942ce53-dirty #335 Not tainted -------------------------------------------- repro/742 is trying to acquire lock: ffff800083702958 (hugetlb_lock){....}-{3:3}, at: free_huge_folio+0x194/0x3c0 but task is already holding lock: ffff800083702958 (hugetlb_lock){....}-{3:3}, at: get_huge_page_for_hwpoison+0x38/ other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(hugetlb_lock); lock(hugetlb_lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by repro/742: #0: ffff800086f942b0 (mf_mutex){+.+.}-{4:4}, at: memory_failure+0x6c/0xdd8 #1: ffff800083702958 (hugetlb_lock){....}-{3:3}, at: get_huge_page_for_hwpoison stack backtrace: CPU: 2 UID: 0 PID: 742 Comm: repro Not tainted 7.0.0-g0eba4942ce53-dirty #335 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: __lock_acquire+0xe7c/0x1e38 lock_acquire+0x2b8/0x3f8 _raw_spin_lock_irqsave+0x74/0xd8 free_huge_folio+0x194/0x3c0 __folio_put+0x124/0x130 __get_huge_page_for_hwpoison+0x138/0x358 get_huge_page_for_hwpoison+0x48/0x78 memory_failure+0xb4/0xdd8 madvise_do_behavior+0x39c/0x660 do_madvise+0xe4/0x158 __arm64_sys_madvise+0x2c/0x48 > > > >