From patchwork Wed Feb 12 20:05:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lucas De Marchi X-Patchwork-Id: 13972402 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 A18C7C021A0 for ; Wed, 12 Feb 2025 20:06:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BB11510E989; Wed, 12 Feb 2025 20:06:09 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="fo7EFa9X"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2DC8B10E97F for ; Wed, 12 Feb 2025 20:06:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739390768; x=1770926768; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SMq3tRylkjXeGIrAENWvMD6N50P9AHGv6CJDNT0dJM0=; b=fo7EFa9Xa56IuCfRSRqVIbDKnPHunJLp/uN/Iohl1JlzPEGxvzdg2U04 ZytHBSxfulY+zaKnTP2HHMxwdo2/1oqkrAImzPOLhJHnmd5sH6mvPuqMa M9Rl2jgZIY+PXz7QRBfu/+o/0AsSNW2KO2u5KtSNGJ6bzwyyLUfmIlITU ot3he3Lz4lN38vtGErJdqJlvm6FsLJykMcddecSDjxnnqMjuNyHKQ/CGw Wt1DK8YpexyDuw1o2/HxdqoHA5GefgKAVqulYCJ+XuAPmudAXOMxcp5im CNxYxIbw6/QLnvTZlyjWkaty9HJzxM0QPT4zZu3ulZmglJZR+/UcA9wql A==; X-CSE-ConnectionGUID: bnxqS8GzTOquoF+jJMqbPQ== X-CSE-MsgGUID: Xt45kivaQM6kp1fpkzOm+w== X-IronPort-AV: E=McAfee;i="6700,10204,11343"; a="50718490" X-IronPort-AV: E=Sophos;i="6.13,280,1732608000"; d="scan'208";a="50718490" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2025 12:06:07 -0800 X-CSE-ConnectionGUID: XsG6tWzXQ22ft0Xl+AHlRg== X-CSE-MsgGUID: VSyvEcdoQzWlgxLF20YJ7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,280,1732608000"; d="scan'208";a="118010754" Received: from lucas-s2600cw.jf.intel.com ([10.165.21.196]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2025 12:06:07 -0800 From: Lucas De Marchi To: linux-kernel@vger.kernel.org Cc: Rodrigo Vivi , dri-devel@lists.freedesktop.org, Danilo Krummrich , "Rafael J. Wysocki" , Greg Kroah-Hartman , Lucas De Marchi Subject: [PATCH 1/6] drivers: base: devres: Allow to release group on device release Date: Wed, 12 Feb 2025 12:05:37 -0800 Message-ID: <20250212200542.515493-2-lucas.demarchi@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250212200542.515493-1-lucas.demarchi@intel.com> References: <20250212200542.515493-1-lucas.demarchi@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. Signed-off-by: Lucas De Marchi Acked-by: Greg Kroah-Hartman --- The check for just an empty devres_head seems simple and sufficient, although the caller of devres_release_group() can still shoot its own foot. I thought about a flag on dev to check it's being removed, but I want to know others' opinions first. 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);