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 505DEC636CD for ; Wed, 1 Feb 2023 13:27:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CEC46B0071; Wed, 1 Feb 2023 08:27:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 67E9E6B0072; Wed, 1 Feb 2023 08:27:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 547736B0074; Wed, 1 Feb 2023 08:27:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4383C6B0071 for ; Wed, 1 Feb 2023 08:27:38 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 103DBAB42B for ; Wed, 1 Feb 2023 13:27:38 +0000 (UTC) X-FDA: 80418800196.06.55D6847 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 2970718001A for ; Wed, 1 Feb 2023 13:27:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1OsUeRe7; dkim=pass header.d=linutronix.de header.s=2020e header.b=5NxabF6m; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675258056; a=rsa-sha256; cv=none; b=MebELukddmuGqNgnidpmfPr7ynhxBF926KHMGJAq2VA5oUQwubQIT5mKNZJ3JkYO0jTwKM WET0UIxcddeOERDuGbY0RAFhaMFDsHtl3uRGpmddT0e+G5VZlaFd1vsqBYT6yX1HaNlR/u CRvAzEoAU0VVs1pzowo3gQJMBHAu+Bs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1OsUeRe7; dkim=pass header.d=linutronix.de header.s=2020e header.b=5NxabF6m; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675258056; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6E/Zy5bjPfbqEf7KZTtuKxX7NxDusFVJ01Vzisn4RWU=; b=d1lXyzJusVNYR3VrrEhigLQn3e7EcGFP0MYSp1NYcAom8m8sIBjWS+5dS6H07OszIuT8cQ me4svNpDe2LIuHgfaCyZ2yOo0tV7pl20EPmOaPUSH8OgDeo9f9qLLYf9x+jvV80Atd4GL1 idZ6iiptSiajqXoSiqe4jrsWMLs5XLk= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1675258053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6E/Zy5bjPfbqEf7KZTtuKxX7NxDusFVJ01Vzisn4RWU=; b=1OsUeRe78OBdcW704sxCwMF6t4Xlp+6nX/ZVsX7bz490eqLhBR6zyBZzXjvv3bKZcR4uPd F4uMmbDHv1KNnzqVUnEOFhm1GmFHARZ20xGDkFK18Vc5IRFs4tCrHbTQNYDTUjRD50Df+R VedwsF8/53YHfidIgsdNDzeoJIn8XxRsgTt+ERCLvozYFq5ydVY4PUyXBeTq6iVCPo9JCJ xpw5tqkZloVnDRkBS4cXpBnpwqsLC+SWqLIDUcV5zURUolrnccU8YyEiarisGUDdpzGE59 DEgTEE9lOZ+2+jdmJ1FcdrbutK2qIn+/25NkN0aq0eNr9k9Qj5WOKmrx7u2riw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1675258053; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6E/Zy5bjPfbqEf7KZTtuKxX7NxDusFVJ01Vzisn4RWU=; b=5NxabF6mLuqwuvxI2LNIiQHaU+3uHJm9egcwksUhan3+JNHB3Ei5xqHNNdxUIE1zhQ6tIV LIyNTnxuUJoLVZDQ== To: kernel test robot , Shanker Donthineni Cc: oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Marc Zyngier , Michael Walle , Sebastian Andrzej Siewior , Hans de Goede , Wolfram Sang , Shanker Donthineni , Vlastimil Babka , linux-mm@kvack.org Subject: Re: [PATCH 5/5] genirq: Use the maple tree for IRQ descriptors management In-Reply-To: <202302011308.f53123d2-oliver.sang@intel.com> References: <202302011308.f53123d2-oliver.sang@intel.com> Date: Wed, 01 Feb 2023 14:27:33 +0100 Message-ID: <87o7qdzfay.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Queue-Id: 2970718001A X-Rspamd-Server: rspam01 X-Stat-Signature: zbqy974xrrctkre83j58wm95tkqhi538 X-HE-Tag: 1675258055-694722 X-HE-Meta: U2FsdGVkX19RBDbetqcWJCdqgaFpBgwaOEOQBGiGF8vNF/ag1/YNOY3Tl38Us+ClZv2mALpEEdwz2/yf+QLhU6r9HKw15CID7Yg4hZhyuFetU+08KwMWNFlXAZlN6F+P9h4WFh4YiSwDXemcZ+Ta5zXdYvMQopUF7mC8hb8vpD6PrbY+AL1TUonFdfww6Dye7nn7OBNuZgUnrGQka5DUeF+rCphlXdz44aUrqXeO3LFVYDBg6VTDUY29Hg0EsY26smiho4tDifgqOGMwM/YR46dBDdehL8Liybak2DO0Ln05PYzYuN+3OB54zYnTJzbWOfOaDyIwqZWCqnDuHgsxT0rajVoHWalN/ygR9B0vLf7qDYc5WmpL/JJMjKUj5mI8weMCJTmDhrg/6Vyev8qTkazrCqtNfwNBzESuewlQZMGUigZHTOZSaWRZHY8mMqICnxXOfjOURdaKxV/umP8LzpWf0/oVNWVSYAY9+NCzLgIBwhyGYEG3x4nFE/5E7o5wEpzTEGQJOMvVh+qPYM0VrImcIHJ4qc4Cf7sX7UYmVhigF5JVstfhjlGwl33kEW4MCLF9B6h6UMBrcSagnDkPZ3CBb7w/pzaq/RWiwAXR++Bdhyij+kUzD6TkSP5RGQ2thY8TbZdsmSbaqL48taWsJNdsooUb65AWB+njpP/4ueaXU5m+uVLkVhJydkxMvvLLAyFLHGEhjrVX9Qdzkybowyyqpww1Xz8+bN16P4rrZ3C3ubJyQslnfSCcVBbOTrcDe4wjOT0qhQMWn/RGLalxL5472ZWY5PDMTLqJcwaAnRQ+2Q+Hvr2qSvQAezV5zyuAOmxQ5quUVKg6EOFz/q1bqf/CcJigy+WIZKbQw6r0o7ahxrNi1/mb8XXv68ntnK9fqSly7xttFMqT9gd5r7rbbSElMxAUUemoAKE2zBwoNL+a+lvx5MXlUFdKJ9unY4kvUHXfSRyuxiLMoRf0Edv oFTMqgzU /nnBTxZcoMo2Ig/5c0/dTSUAvUsfklbSrvA7jO7zFU5B3+4Eks5P5NhOg1J6qwe9N49cHbuRsstBZERgFLxJa3a+WxyJdc++Wr/6o08+oYKq3jP1oRIU0sglUk6dk3JWCmXHf/u+r0GZohGObNdm4y2TIF11A+T1JpXXaDSc1ZmcCQX8C8Lvhlx5mAfrr5Kxl67361RM62lI1o3elgHc8BXEQy8cfAYv6HkZeikn9G9Xzk3KM4gBWHWUFEyqMC/NUBdMg 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: On Wed, Feb 01 2023 at 14:02, kernel test robot wrote: > FYI, we noticed WARNING:at_kernel/locking/lockdep.c:#lockdep_hardirqs_on_prepare due to commit (built with gcc-11): > > commit: 02fb8013ee5f9b7d7bc35d54bf8bc5fe1179970c ("[PATCH 5/5] genirq: Use the maple tree for IRQ descriptors management") > url: https://github.com/intel-lab-lkp/linux/commits/Shanker-Donthineni/genirq-Use-hlist-for-managing-resend-handlers/20230130-085956 > base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git 188a569658584e93930ab60334c5a1079c0330d8 > patch link: https://lore.kernel.org/all/20230130005725.3517597-6-sdonthineni@nvidia.com/ > patch subject: [PATCH 5/5] genirq: Use the maple tree for IRQ > descriptors management > [ 2.214554][ T0] ------------[ cut here ]------------ > [ 2.215401][ T0] DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled) > [ 2.215446][ T0] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4308 lockdep_hardirqs_on_prepare+0x2d4/0x350 > [ 2.217975][ T0] Modules linked in: > [ 2.218526][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.2.0-rc3-00015-g02fb8013ee5f #1 > [ 2.219803][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 > [ 2.221228][ T0] RIP: 0010:lockdep_hardirqs_on_prepare+0x2d4/0x350 > [ 2.222207][ T0] Code: 11 38 d0 7c 04 84 d2 75 5e 8b 0d bf 8b f7 03 85 c9 0f 85 c9 fe ff ff 48 c7 c6 40 7d a9 83 48 c7 c7 60 4e a9 83 e8 60 7c 35 02 <0f> 0b e9 af fe ff ff e8 50 8d 62 00 e9 0c fe ff ff e8 e6 8d 62 00 > [ 2.224923][ T0] RSP: 0000:ffffffff844075a0 EFLAGS: 00010082 > [ 2.225792][ T0] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 > [ 2.226889][ T0] RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffbfff0880ea6 > [ 2.227955][ T0] RBP: ffff8883af23fac0 R08: 0000000000000000 R09: ffffffff844072df > [ 2.229068][ T0] R10: fffffbfff0880e5b R11: 0000000000000001 R12: 0000000000000002 > [ 2.230147][ T0] R13: 0000000000000002 R14: ffff88810022b018 R15: ffff88810022b010 > [ 2.231269][ T0] FS: 0000000000000000(0000) GS:ffff8883af200000(0000) knlGS:0000000000000000 > [ 2.232522][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 2.233395][ T0] CR2: ffff88843ffff000 CR3: 000000000442a000 CR4: 00000000000406b0 > [ 2.234504][ T0] Call Trace: > [ 2.234941][ T0] > [ 2.235345][ T0] trace_hardirqs_on+0x40/0x140 > [ 2.236029][ T0] __kmem_cache_alloc_bulk+0x22e/0x490 > [ 2.236795][ T0] ? kasan_set_track+0x25/0x30 > [ 2.237470][ T0] kmem_cache_alloc_bulk+0x159/0x2e0 > [ 2.238225][ T0] mas_alloc_nodes+0x253/0x690 > [ 2.238886][ T0] mas_split+0x30d/0x1580 > [ 2.239561][ T0] ? mas_push_data+0x1a40/0x1a40 > [ 2.240219][ T0] ? memset+0x24/0x50 > [ 2.240782][ T0] ? blake2s_final+0x110/0x140 > [ 2.241426][ T0] ? blake2s+0x115/0x150 > [ 2.242143][ T0] ? wait_for_random_bytes+0xd0/0xd0 > [ 2.242859][ T0] ? mas_mab_cp+0x2f6/0x890 > [ 2.243527][ T0] ? memset+0x24/0x50 > [ 2.244122][ T0] ? find_held_lock+0x2c/0x110 > [ 2.244803][ T0] ? mas_store_b_node+0x54c/0x1180 > [ 2.245510][ T0] ? rcu_read_lock_sched_held+0x16/0x80 > [ 2.246282][ T0] mas_wr_bnode+0x14f/0x1d0 > [ 2.246902][ T0] ? mas_commit_b_node+0x600/0x600 > [ 2.247677][ T0] ? secondary_startup_64_no_verify+0xe0/0xeb > [ 2.248567][ T0] ? ___slab_alloc+0x70b/0xe00 > [ 2.249251][ T0] ? mas_wr_store_entry+0x2e9/0xe30 > [ 2.250088][ T0] ? rcu_read_lock_sched_held+0x16/0x80 > [ 2.250864][ T0] mas_store_gfp+0xc2/0x190 > [ 2.251516][ T0] ? mtree_erase+0x100/0x100 > [ 2.252190][ T0] ? lockdep_init_map_type+0x2c7/0x780 > [ 2.252924][ T0] irq_insert_desc+0xac/0xf0 > [ 2.253562][ T0] ? irq_kobj_release+0x100/0x100 > [ 2.254243][ T0] early_irq_init+0x81/0x8c > [ 2.254866][ T0] start_kernel+0x1c7/0x3a4 > [ 2.255479][ T0] secondary_startup_64_no_verify+0xe0/0xeb This triggers because __kmem_cache_alloc_bulk() uses lock_irq()/unlock_irq(). Seems nobody used it during early boot stage yet. Though the maple tree conversion of the interrupt descriptor storage which is the purpose of the patch in question makes that happen. Fix below. Thanks, tglx --- Subject: mm, slub: Take slab lock with irqsave() From: Thomas Gleixner Date: Wed, 01 Feb 2023 14:14:00 +0100 Signed-off-by: Thomas Gleixner --- mm/slub.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/mm/slub.c +++ b/mm/slub.c @@ -3913,6 +3913,7 @@ static inline int __kmem_cache_alloc_bul size_t size, void **p, struct obj_cgroup *objcg) { struct kmem_cache_cpu *c; + unsigned long irqflags; int i; /* @@ -3921,7 +3922,7 @@ static inline int __kmem_cache_alloc_bul * handlers invoking normal fastpath. */ c = slub_get_cpu_ptr(s->cpu_slab); - local_lock_irq(&s->cpu_slab->lock); + local_lock_irqsave(&s->cpu_slab->lock, irqflags); for (i = 0; i < size; i++) { void *object = kfence_alloc(s, s->object_size, flags); @@ -3942,7 +3943,7 @@ static inline int __kmem_cache_alloc_bul */ c->tid = next_tid(c->tid); - local_unlock_irq(&s->cpu_slab->lock); + local_unlock_irqrestore(&s->cpu_slab->lock, irqflags); /* * Invoking slow path likely have side-effect @@ -3956,7 +3957,7 @@ static inline int __kmem_cache_alloc_bul c = this_cpu_ptr(s->cpu_slab); maybe_wipe_obj_freeptr(s, p[i]); - local_lock_irq(&s->cpu_slab->lock); + local_lock_irqsave(&s->cpu_slab->lock, irqflags); continue; /* goto for-loop */ } @@ -3965,7 +3966,7 @@ static inline int __kmem_cache_alloc_bul maybe_wipe_obj_freeptr(s, p[i]); } c->tid = next_tid(c->tid); - local_unlock_irq(&s->cpu_slab->lock); + local_unlock_irqrestore(&s->cpu_slab->lock, irqflags); slub_put_cpu_ptr(s->cpu_slab); return i;