From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 1330F1C5D59 for ; Wed, 20 May 2026 08:13:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779264833; cv=none; b=ZuVbIEXVAKb2BrZkwlyYD+yq9xZCQZ4xlAjV7P2cD3YJjX35q+OmtxG46ndmW/mB/YTqBrynRsWg1tglQn0/xvze0BOtusvQemZH2tUtbiqLmQlIQJ0bb5JV8NhBrYzKab6pY7xwyLtQb+2gAxvAD2ThZi74RljLsIgWGjBmHeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779264833; c=relaxed/simple; bh=h4dFhIVlaVNymmP5wQerMI/LY/OI4deukcDSWtubutw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L8mW8qSMHqi5Aoa/mD5Ah7jZIcefR3YsH6XIASqnbFucw7rapoVQ0o7zg2BeIPAF4Rw25j2oWvZ/MCwdCECViTg6XUXhN3exfv6p59I/YGPuQVrn3NWUm2vozXcwK6eFYcuwckuzKxZmyIzife7+g//YbATUXJZSkB6lQalUS0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TfwXQElo; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TfwXQElo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D5421F000E9; Wed, 20 May 2026 08:13:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779264831; bh=HCQt92sZnLpz6/MMNIMsDZndfozm7C4EUpvW4TEtXNw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TfwXQEloIp7hzqgCsIq5nPEkWoivA6fOgkIr0TAwADyYtMMQmHN92tMOq1Jrx/RAo eq0xfV5fjg+nNHdOd9y5qaIqVhp990WKyaCEYRmvs0LIy/EONqaP85Nhfm/asKIHCq Sm7ZC3nhjw0HfK2lYb2O4H14LD7Zaziw+gdCD9VWoe0t1hjya+YikgaLj4AkPQv4ld pHDTbOeWGmCyRXzohpNx3ykW49Ox3cVtF3L1DxKV4UNnsljqp2Nhi2wiDqDtQsIiX1 7PP1Yhzy+nNRx5PEPGgInqynLR5vgUUkOtKDy5NcxGJemIGY60IHlg8aaoeuIpWvXs n+TgYak3zAfpw== Date: Wed, 20 May 2026 10:13:42 +0200 From: "Oscar Salvador (SUSE)" To: Wupeng Ma Cc: muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, akpm@linux-foundation.org, ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linmiaohe@huawei.com, nao.horiguchi@gmail.com, mike.kravetz@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison Message-ID: References: <20260520020128.3506168-1-mawupeng1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260520020128.3506168-1-mawupeng1@huawei.com> 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? -- Oscar Salvador SUSE Labs