From nobody Wed Dec 17 10:24:50 2025 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 7ACBD12FF71 for ; Thu, 11 Jul 2024 07:14:35 +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=1720682078; cv=none; b=IzxTOMlxgyMv/n9hCUf4dlNDnbrOcBxO0cE88y97Jfa6OCt4ACyXABTNxtAwbIk0+5kw/uV1ILFjrfEiaMhIX67xta1PRCDbGeCe2c7oUg57/NCh6sE2XKhHmIQMbPcN93s1ENozxKQm8a3t1I74MczlspRFxKSczLiI522VGj4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720682078; c=relaxed/simple; bh=umgp6A9ocfsCRENUP33QgEjljReB72E+CZe+xkKrGfY=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=TsI/bkmQOsC/gjwqZxb8zZpsZ5l2IVZre0YBb43UdLOzdij5ieT2lhXsz8NNNOqJ/JCb2tKwDdWlsnVTzxPcbJFz3GIVqn/VVrIBGNToGx3sbRSnIhN8wEVD57IAVcWzBZ2y52bZPeW2dd8HC6rMlbCo7gqj3LY6BAhkJA6M5HI= 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.163.44]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4WKQss6qrbz1xtVx; Thu, 11 Jul 2024 15:12:49 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id 1D5E014010C; Thu, 11 Jul 2024 15:14:26 +0800 (CST) Received: from huawei.com (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; Thu, 11 Jul 2024 15:14:25 +0800 From: Miaohe Lin To: , CC: , , Subject: [PATCH] mm/hugetlb: fix possible recursive locking detected warning Date: Thu, 11 Jul 2024 15:10:01 +0800 Message-ID: <20240711071001.3475337-1-linmiaohe@huawei.com> X-Mailer: git-send-email 2.33.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemd200019.china.huawei.com (7.221.188.193) Content-Type: text/plain; charset="utf-8" When tries to demote 1G hugetlb folios, a lockdep warning is observed: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty #79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter= +0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_ite= r+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/= 0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty= #79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g1= 55821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Fixes: 8531fc6f52f5 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin --- mm/hugetlb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 45fd3bc75332..2004e6d3f7ca 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4659,6 +4659,8 @@ bool __init __attribute((weak)) arch_hugetlb_valid_si= ze(unsigned long size) return size =3D=3D HPAGE_SIZE; } =20 +static struct lock_class_key hugetlb_resize_keys[HUGE_MAX_HSTATE]; + void __init hugetlb_add_hstate(unsigned int order) { struct hstate *h; @@ -4671,6 +4673,7 @@ void __init hugetlb_add_hstate(unsigned int order) BUG_ON(order < order_base_2(__NR_USED_SUBPAGE)); h =3D &hstates[hugetlb_max_hstate++]; mutex_init(&h->resize_lock); + lockdep_set_class(&h->resize_lock, &hugetlb_resize_keys[hstate_index(h)]); h->order =3D order; h->mask =3D ~(huge_page_size(h) - 1); for (i =3D 0; i < MAX_NUMNODES; ++i) --=20 2.33.0