From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05A5D392C27; Wed, 25 Feb 2026 11:22:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772018534; cv=none; b=GIV7gT7T+5tyo3k1jXfHLq8BDM6uoCI9Q3TGnzw+aL3py2WSnAkvveS1OW/aGkwNV7ahXLDJgIuQbdXuEAT4ZfXVAoY+GwvQzo1WbwL88ot4ESbvVXswjxn6xT26oNXVbsv3Z9ghyVIeVVmxxzpQo6LuDJ75LjMXZnyhyxBV6h0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772018534; c=relaxed/simple; bh=rUzBkuQkbcby7iWW2iWJc3QofzuYy/ux28qQ20LwUq4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W5pod6N2OWQ4RfM03Mrf0TAbiycIKZM6LgjdcG5XgVFCYmdh5CGPI3Kso9/pnXhtiUf6QFDNGW30Sd8jmGcuxPbyz7hDb1YcdqmUmrMsHRI2HQxU0lZvutsq3VMNWsg89N3xI9dPrBYiZNyF21jQJsPSwdL+mHdxg3prgirFagU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JqEYay01; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JqEYay01" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772018532; x=1803554532; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=rUzBkuQkbcby7iWW2iWJc3QofzuYy/ux28qQ20LwUq4=; b=JqEYay01kGP+2jaL89nXDuPewritBFT7kP2gA8jJeVniU7FiAmsxswgt ho0YiqLvsJFN1YI3NEQR8wTtRft2T37+4f3r+d0j9VRAP61rwFVGsjck4 UZX/ucn8kjIba/SWZsvHYeUWsk6ZcCoxtQjPnJnJA3QxQOii3Uci4IwlZ NSjiJyzIR0L9Tsxn5iyCiS6dHC6PJfi7ChkHDjqBNfD2cW83bC48311C3 o2/VR8KcUikICzLmYJp80XotJsyGemgOVghCdQlhRe6pwnQX9BSImQJEp 5DM1DUoSujcg+w44vjkjsLV9q4pUVYRg/MC1w7TahNzSKzPRbX+RqcX30 g==; X-CSE-ConnectionGUID: y1XyCPvgQE68SmqrVwZPFA== X-CSE-MsgGUID: 9jWpVIJUSn6SJxAscPgapg== X-IronPort-AV: E=McAfee;i="6800,10657,11711"; a="75660994" X-IronPort-AV: E=Sophos;i="6.21,310,1763452800"; d="scan'208";a="75660994" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2026 03:22:11 -0800 X-CSE-ConnectionGUID: xt+iP5quSM6A4s6OyK9Kvg== X-CSE-MsgGUID: 5MupqhvFQZK/5wwKyYX9AQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,310,1763452800"; d="scan'208";a="220809845" Received: from vpanait-mobl.ger.corp.intel.com (HELO localhost) ([10.245.244.71]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2026 03:22:09 -0800 Date: Wed, 25 Feb 2026 13:22:07 +0200 From: Andy Shevchenko To: mike.isely@cobaltdigital.com Cc: Daniel Scally , Heikki Krogerus , Sakari Ailus , Mike Isely , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] sofware node: Only the managing device can unreference managed software node Message-ID: References: <20260224191922.2972974-1-mike.isely@cobaltdigital.com> <20260224191922.2972974-2-mike.isely@cobaltdigital.com> Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260224191922.2972974-2-mike.isely@cobaltdigital.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Feb 24, 2026 at 01:19:22PM -0600, mike.isely@cobaltdigital.com wrote: > From: Mike Isely Author's and... > A scenario exists where device_create_managed_software_node() is used > to create an swnode instance that will be implicitly shared to a child > device despite best intentions not to permit such sharing (per the > comment in device_create_managed_software_node()). I encountered this > with the sfp kernel module when it was instantiated with properties SFP? Or is it the name of the actual module in the kernel? > via a call to platform_device_register_full() - it will create hwmon > child devices which get all property references. Unfortunately with > just a "managed" boolean in struct swnode handling this, then > kobject_put() gets called for the managed aspect when the child device > goes away instead of the parent. This leads to premature freeing of > the swnode structure, followed by use-after-free problems, heap > corruption, and generally chaos / crashes / misbehavior in the kernel. > > This commit changes that boolean into a pointer to the actual managing > struct device, which is then checked against the struct device > instance that is actually going away (via the usual call back into > software_node_notify_remove()). Thus the child device removal is > ignored as it should, and we only do the kobject_put() when the actual > managing struct device instance goes away. We effectively carry a > little bit more information now so that we can be sure to clean up > only when the correct struct device instance is actually going away. > > Note that while we are now keeping a pointer to a struct device here, > this is safe to do because the pointer itself only stays in use while > the pointed-to device remains valid. (So no need to be concerned > about additional reference counting.) The term is called "object lifetime". > Signed-off-by: Mike Isely ...submitter's addresses are different. Either it should be send from the mentioned address, or you should have From: Author <...> ... SoB: Author <...> SoB: Submitter <...> ... What about the use case (don't know if it's pure theoretical or practical) when there is a parent and a few children and the managed swnode appears in one of the children? With some other dependencies between children it might affect how swnode is get cleaned up. Simple and regular approach is to cleanup children in the reversed order, but I can't say that it's always the case. Some children in some corner cases might have their own dependencies (I saw some strange devices or device drivers where the HW is a bit complicated and driver is written without much care). -- With Best Regards, Andy Shevchenko