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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 48F4BC021B3 for ; Sat, 22 Feb 2025 00:11:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E36B310EB40; Sat, 22 Feb 2025 00:11:09 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="kyTnMcXg"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by gabe.freedesktop.org (Postfix) with ESMTPS id 14FB510E10F for ; Sat, 22 Feb 2025 00:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1740183069; x=1771719069; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=rYp36tTCtusfp6VSWc8Op8Sp2tfTFlE+T6/+mtqFXDc=; b=kyTnMcXgSYwuIU8BjcEDYl4bHHwAqGzBuHmYfw+2kaeDmGkbpYAnhBOU WQeYaLLfgQcrOuzOpmve45PBMjzKy8aGjOB4coHKy8Q2GyUm9K5ugQnCh r5Kr0Yz+xesVl2lLuvv+dnQyIUWYTKQiwSx9rq6XRdleIYM4pMf+S34qe HEwgrbnV7+CM0LFA07w8i+Hpv9vRcxSkDLK60qUwCxy7BiMLi8EeVLV++ DUSCTwj6PJitG/EAeXysdoL7b+TG6xxUq2f6yIijnH2ISeWaZ+XAZl8ht c3JfB0taQiEQ/IojKFf2vfF6XkQ9GLmMrhiOSHT/zs0dPA8TYnvm1Y862 A==; X-CSE-ConnectionGUID: 4UosrvAgTrWOLWYKZpgwTg== X-CSE-MsgGUID: 9Xv/XnEBRHmWf2PDqDWB7g== X-IronPort-AV: E=McAfee;i="6700,10204,11352"; a="44926386" X-IronPort-AV: E=Sophos;i="6.13,306,1732608000"; d="scan'208";a="44926386" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2025 16:11:08 -0800 X-CSE-ConnectionGUID: dj5ISlwcQl2q/zSlW7UYoQ== X-CSE-MsgGUID: S/eYw/f3Q6GLnF62n4UvkA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,306,1732608000"; d="scan'208";a="115704928" Received: from lucas-s2600cw.jf.intel.com ([10.165.21.196]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2025 16:11:08 -0800 From: Lucas De Marchi To: Subject: [PATCH v2 01/11] drivers: base: devres: Allow to release group on device release Date: Fri, 21 Feb 2025 16:10:41 -0800 Message-ID: <20250222001051.3012936-2-lucas.demarchi@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250222001051.3012936-1-lucas.demarchi@intel.com> References: <20250222001051.3012936-1-lucas.demarchi@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" When releasing a device, if the release action causes a group to be released, a warning is emitted because it can't find the group. This happens because devres_release_all() moves the entire list to a todo list and also move the group markers. Considering r* normal resource nodes and g1 a group resource node: g1 -----------. v v r1 -> r2 -> g1[0] -> r3-> g[1] -> r4 After devres_release_all(), dev->devres_head becomes empty and the todo list it iterates on becomes: g1 v r1 -> r2 -> r3-> r4 -> g1[0] When a call to component_del() is made and takes down the aggregate device, a warning like this happen: RIP: 0010:devres_release_group+0x362/0x530 ... Call Trace: component_unbind+0x156/0x380 component_unbind_all+0x1d0/0x270 mei_component_master_unbind+0x28/0x80 [mei_hdcp] take_down_aggregate_device+0xc1/0x160 component_del+0x1c6/0x3e0 intel_hdcp_component_fini+0xf1/0x170 [xe] xe_display_fini+0x1e/0x40 [xe] Because the devres group corresponding to the hdcp component cannot be found. Just ignore this corner case: if the dev->devres_head is empty and the caller is trying to remove a group, it's likely in the process of device cleanup so just ignore it instead of warning. Acked-by: Greg Kroah-Hartman Reviewed-by: Rodrigo Vivi Signed-off-by: Lucas De Marchi --- drivers/base/devres.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/devres.c b/drivers/base/devres.c index 93e7779ef21e8..b955a2f9520bf 100644 --- a/drivers/base/devres.c +++ b/drivers/base/devres.c @@ -687,6 +687,13 @@ int devres_release_group(struct device *dev, void *id) spin_unlock_irqrestore(&dev->devres_lock, flags); release_nodes(dev, &todo); + } else if (list_empty(&dev->devres_head)) { + /* + * dev is probably dying via devres_release_all(): groups + * have already been removed and are on the process of + * being released - don't touch and don't warn. + */ + spin_unlock_irqrestore(&dev->devres_lock, flags); } else { WARN_ON(1); spin_unlock_irqrestore(&dev->devres_lock, flags); -- 2.48.1