From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C5B2C3DA49 for ; Fri, 12 Jul 2024 02:08:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F4DC6B008C; Thu, 11 Jul 2024 22:08:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A4676B0092; Thu, 11 Jul 2024 22:08:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 893726B0093; Thu, 11 Jul 2024 22:08:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6CB2B6B008C for ; Thu, 11 Jul 2024 22:08:40 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0B4CA1407A9 for ; Fri, 12 Jul 2024 02:08:40 +0000 (UTC) X-FDA: 82329466800.06.CE7C888 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf30.hostedemail.com (Postfix) with ESMTP id 439E88000D for ; Fri, 12 Jul 2024 02:08:36 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720750084; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+uDaWmpSHCB6BF9W/LYbzf3VFycdIBvBDy5WxC1Z/Gw=; b=6FisZ1QgAQYQwNQAdrQ0FdDLa3yT9G7as/Pj3nc5Y6k8xSMCuoNXdT3SWY8rCLUZnCljGb 2kF1um7qk9G3ZOonCNHejFRGZOheZZmilX9VfFlLUKBKwF5F90tHQ6j4KzJS4uXUusUs+n ltYh5qT93SSENMkJPAEHCcjh1COBgfA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720750084; a=rsa-sha256; cv=none; b=wlyfEZ+WdHikYztmT92AKer7JNnXEZkq/elHnt916/CYVF6FvwZpbT0IhUN+Q8jvgfZn2R SL7pOcX9iP/tELLMpP4CGaQ8DhKjA7+6QmBr+qf6sdhj1/B/rGRR2/f+7l360oLE9lGNBx jky5bCvHQkQjSPQS33B3TqiM0o+NjSo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4WKvzR4DFrz1X4k0; Fri, 12 Jul 2024 10:04:19 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id C6C04140337; Fri, 12 Jul 2024 10:08:33 +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; Fri, 12 Jul 2024 10:08:33 +0800 Subject: Re: [PATCH] mm/hugetlb: fix possible recursive locking detected warning To: Muchun Song CC: Andrew Morton , Linux-MM , LKML References: <20240711071001.3475337-1-linmiaohe@huawei.com> <4A12CD33-A3C4-4328-ACB5-CF08C8202DC9@linux.dev> From: Miaohe Lin Message-ID: Date: Fri, 12 Jul 2024 10:08:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <4A12CD33-A3C4-4328-ACB5-CF08C8202DC9@linux.dev> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.127.72] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemd200019.china.huawei.com (7.221.188.193) X-Stat-Signature: 99ofidw8rodo8aztmmrnjg99uby6beho X-Rspamd-Queue-Id: 439E88000D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720750116-414974 X-HE-Meta: U2FsdGVkX1+DdlLHmRpcb8QCteMrHnjYzyNBARF0Nq49bIYvyP3lEf/y/N3MD21cCUK9ipLpmx2odaayBaAj2UcNPYZRcAc0Xv8NU4qHRk1xT3miJ0/21JLfMmvvXUwnd9FgUiShCXxEwHXyXSCPijXcLEvbXyTVa5+H28A2T+gqa7DEscxtw8stYp0LIt/KwuWXskh79oNyaPr0RulJSSnD5vG+0g45q6RnrjXH2L1Qc9YYigzpyaIcKymd9ZCFU/PTN9UF2J3v06swA6E+f9sNrv+XChJnnJC8Wm39Ia7p+uB85wAklQo5Hl0AKuon+cKQOYByFlxUz41+XxUdIYrBl5wQzOfCiM0XfCWBvpcKlBN9FMqHY6PiZRPwyzX0aGeMYeo6Xr89bXGS9pUWO+laUXFEgMLce0tBJ7kEykxGnMbSMLIPZI4WcGaUw+eJunJMXmK13UzjuAVr6snt0HS/AfU38g1itrg9dI4jRcItzGkYj/0QFa2NcgRJiWeMbYwhWIhS2hkeR+V2uMBle12Eg8KmcKQpM9kHZC+UQw/Wto6r1ii8GGQtpS4Jk9lWVMieRyO5qVZeK7h+R9v1AGNEe3toLT8FlxhRe3Nbfo06SfceEbLjTQ1gBE18A37fK95pfMTAtaimIo9O83gFMO8kIO6KfxI/B4qGrXFmyTxu7eFeN4e3yWRIlJQ41SIYCEWp7+VKInl61YOhY/NA1sO5DlA+oTTD3HjRYONBcNIRwpVlLJSFUMkLgyWUileNaxbzum75zRiK6dJpnjiqR8S937ip5rpGgJxfIf/7ncetM0kylN1pAy6o2F834hckIJKjiDaqlkW5gMBvb4UDcL7lCJEPbML0jwNvwdLvJmqQ5lAlkJ9bLUlDoIJf773XfkBt85aV5JiLL7GJDugifGGUUeBhfxhL9c1OTUlJ3x5gEoMZjPl219HbYhDW23MgeMFDApuG4azdGITX+iz 1dLYlMC+ rZs/K9OhW6kE+GFthjqmHl+TPM9WYx9fQBr+8V0RS98cP2PhsWbhVULOmKCh1jcTTpbTXJlcb82VIi42zUIW5JvhnpneX93TrOGXgDsbwL8G2rfa3Lhs6vSXrZR7At/WmOmrZBDXV1F7dXHl9uNXrnNpziZMcCNGyHTYmjbVmN+QG9icI6uWWNPPcnJ46sIwcmzToiBGinPu2dZbzUWKWgNZ5bA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/7/11 16:27, Muchun Song wrote: > > >> On Jul 11, 2024, at 15:10, Miaohe Lin wrote: >> >> When tries to demote 1G hugetlb folios, a lockdep warning is observed: >> >> ============================================ >> 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_iter+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-g155821a1990b-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_size(unsigned long size) >> return size == HPAGE_SIZE; >> } >> >> +static struct lock_class_key hugetlb_resize_keys[HUGE_MAX_HSTATE]; > > It's better to let this into "struct 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 = &hstates[hugetlb_max_hstate++]; >> mutex_init(&h->resize_lock); > > mutex_init() already declares a lock_class_key structure by itself, in > order to avoid this, you should use __mutex_init(). While searching the code, I find we can do this in two ways: 1.__mutex_init with separate lock_class_key 2.mutex_init + lockdep_set_class These are all fine to me. And I will use __mutex_init and move hugetlb_resize_keys into "struct hstate" as you suggested. Thanks. .