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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A352AC3DA6E for ; Thu, 28 Dec 2023 10:36:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=eSUzD7VCK8f90ZMqI7TsukBfmJwpqSBWnXBamEAE2FM=; b=EcFUdrDesh/L5fPjr0JNWnRXEj YE0KLUMqPxexpdayNIqMRMp5QDTmlabO4ZRou85nE06MV8GFE3Q9zlxoOJr15LA+aPxW8XHmEU1qj ONv13lZhwilOTBwX9AnGsUv3g3KXnYWsmCcIvAleh+Adsph+rdZDl3F0oAUHus5H6O27olY77SKqi AzCQau4PdduyzGAzltukemkv8qy6yGKmsrtow2Gj5CEDthPzM/lUqSgt5K3+otTDN81YQToDIlAhZ /7g3nik1KVSjNEZfj85TpCofsICgI+omfdDzkWwl4Gk1f/oez7198kSsoZxrO6pKEbXnWpgKjjCgq qMXnEfHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rInjm-00GYsH-1m; Thu, 28 Dec 2023 10:35:38 +0000 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rInjh-00GYrs-2r for linux-arm-kernel@lists.infradead.org; Thu, 28 Dec 2023 10:35:36 +0000 Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=ratatoskr.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rInjb-0004R6-9D; Thu, 28 Dec 2023 11:35:27 +0100 User-agent: mu4e 1.10.8; emacs 29.1 From: Steffen Trumtrar To: Sean Anderson Cc: Camelia Groza , Li Yang , David S. Miller , linux-arm-kernel@lists.infradead.org Subject: [BUG] soc: fsl: qbman: lockdep invalid wait context with qman_update_cgr_smp_call Date: Thu, 28 Dec 2023 11:19:06 +0100 Message-ID: <87wmsyvclu.fsf@pengutronix.de> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: s.trumtrar@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231228_023533_946206_B94D9DDA X-CRM114-Status: GOOD ( 12.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, I noticed that lockdep reports a BUG on the qman driver since 914f8b228ede709274b8c80514b352248ec9da00 Author: Sean Anderson AuthorDate: Fri Sep 2 17:57:35 2022 -0400 Commit: David S. Miller CommitDate: Mon Sep 5 14:27:39 2022 +0100 soc: fsl: qbman: Add CGR update function This adds a function to update a CGR with new parameters. qman_create_cgr can almost be used for this (with flags=0), but it's not suitable because it also registers the callback function. The _safe variant was modeled off of qman_cgr_delete_safe. However, we handle multiple arguments and a return value. The stack trace looks something like: [ 20.192060] ============================= [ 20.196067] [ BUG: Invalid wait context ] [ 20.200073] 6.7.0-rc6 #73 Not tainted [ 20.203733] ----------------------------- [ 20.207738] systemd-journal/114 is trying to lock: [ 20.212528] ffff000973403860 (&portal->cgr_lock){+.+.}-{3:3}, at: qman_update_cgr_smp_call+0x40/0xb0 [ 20.221688] other info that might help us debug this: [ 20.226736] context-{2:2} [ 20.229350] 1 lock held by systemd-journal/114: [ 20.233878] #0: ffff0008001a0208 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_iop_permission+0x48/0xa0 [ 20.243902] stack backtrace: [ 20.246779] CPU: 2 PID: 114 Comm: systemd-journal Not tainted 6.7.0-rc6 #73 [ 20.253743] Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (AT300) board (DT) [ 20.261144] Call trace: [ 20.261147] dump_backtrace+0xa0/0x128 [ 20.261154] show_stack+0x20/0x38 [ 20.261158] dump_stack_lvl+0x74/0xd8 [ 20.274303] dump_stack+0x18/0x28 [ 20.279004] __lock_acquire+0x920/0x1b58 [ 20.284309] lock_acquire+0x1fc/0x348 [ 20.289354] _raw_spin_lock_irqsave+0x6c/0xd0 [ 20.294748] qman_update_cgr_smp_call+0x40/0xb0 [ 20.299278] __flush_smp_call_function_queue+0x1d0/0x3e0 [ 20.304593] generic_smp_call_function_single_interrupt+0x1c/0x30 [ 20.310689] ipi_handler+0x250/0x290 [ 20.314263] handle_percpu_devid_irq+0xb0/0x170 [ 20.318793] generic_handle_domain_irq+0x34/0x58 [ 20.323411] gic_handle_irq+0x4c/0xd8 [ 20.327070] call_on_irq_stack+0x24/0x58 [ 20.330991] do_interrupt_handler+0xdc/0xe8 [ 20.335173] el1_interrupt+0x34/0x68 [ 20.338747] el1h_64_irq_handler+0x18/0x28 [ 20.342843] el1h_64_irq+0x64/0x68 [ 20.346240] lock_acquired+0x198/0x448 [ 20.349988] down_read+0x98/0x1c0 [ 20.353300] kernfs_iop_permission+0x48/0xa0 [ 20.357569] inode_permission+0x118/0x190 [ 20.361578] link_path_walk.part.0.constprop.0+0x2b0/0x398 [ 20.367065] path_lookupat+0x44/0x1b8 [ 20.370726] filename_lookup+0x9c/0x170 [ 20.374561] user_path_at_empty+0x54/0x88 [ 20.378571] do_faccessat+0x88/0x308 [ 20.382144] __arm64_sys_access+0x2c/0x40 [ 20.386152] invoke_syscall+0x50/0x120 [ 20.389901] el0_svc_common.constprop.0+0xc8/0xf0 [ 20.394606] do_el0_svc_compat+0x24/0x40 [ 20.398528] el0_svc_compat+0x4c/0x148 [ 20.402275] el0t_32_sync_handler+0xb0/0x138 [ 20.406545] el0t_32_sync+0x194/0x198 The [ 20.207738] systemd-journal/114 is trying to lock: can be any other process and must not be systemd-journal. For example when barebox-state triggers the stacktrace the function calls look like: # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | systemd-1 [002] ...2. 6.871198: qm_modify_cgr <-qman_init_cgr_all (...) kworker/2:1-38 [002] ...1. 19.070335: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed barebox-state-211 [001] d.h1. 19.070344: qman_update_cgr_smp_call <-__flush_smp_call_function_queue barebox-state-211 [001] d.h3. 19.260311: qm_modify_cgr <-qman_update_cgr_smp_call kworker/2:1-38 [002] ...1. 19.305517: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed -0 [001] d.h2. 19.305524: qman_update_cgr_smp_call <-__flush_smp_call_function_queue -0 [001] d.h4. 19.305526: qm_modify_cgr <-qman_update_cgr_smp_call kworker/3:1-40 [003] ...1. 19.354259: qman_update_cgr_safe <-dpaa_eth_cgr_set_speed -0 [001] d.h2. 19.354265: qman_update_cgr_smp_call <-__flush_smp_call_function_queue -0 [001] d.h4. 19.354267: qm_modify_cgr <-qman_update_cgr_smp_call I'm not sure why the CPU# detection in the patch is necessary, but maybe you have an idea what is happening here. Best regards, Steffen -- Pengutronix e.K. | Dipl.-Inform. Steffen Trumtrar | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel