From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 471AC3B8BA0 for ; Tue, 20 Jan 2026 10:18:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768904317; cv=none; b=BS2I3AuGrKu5yjBUavJ1637pjJBEY8LJed2/Ecpp93rZU3oQeOZbydTKR7gIs4rtPaQqsw7wGnOAv6yDfNYmOPfnAg9mVJRWC6BEyhKUb6fABZQNPDCW1C6+2630F0o2oR4ws4WFwQV+OJkZ5aRW34zMGrKnM3GmgN320VGuIe0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768904317; c=relaxed/simple; bh=7www/rNy8TMayH+a4qDU4EBzXlL8Zwyo9Im09zU7YsU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ucLdv3rIv6B0p31WN6mOhsoAoup4Mwmp4nkT5vaGQCuITkxf08Ky/Y3SMMqVzIUMjY812xlcg7hwBnDz3nDemIukEGAxYA2szwGYJFAf2zmS9aj94DQa2mXAx9YEEUzK3JuR24/JhbEcvA9eOivJ1OZS5Gsqwtxu0DtRcOFOSho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uNbLVIAC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uNbLVIAC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C934EC16AAE; Tue, 20 Jan 2026 10:18:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768904316; bh=7www/rNy8TMayH+a4qDU4EBzXlL8Zwyo9Im09zU7YsU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uNbLVIACJJqeUn78k6UkleOdgmwA4PjdUMjiQryKU5fJPe1cfVZnhLck+VGSdwDRO Y4RsKUJRIuk77JoDkuXmt4dxm/ANElV8+uAGc9x3EGzZ49oBM8KWN7p0JEQrawZNEn 0rZeRrrM/Kc3MMJU3jO67CYEwlUgPWBk0++ugcREJagvwM7avl9VAlSHQXvd0vxq/K kLdQBCjhC9RgrbHYa71Rmq90nfiPHLRWYtk2enuNQbDtyej9aPPt/xO8Oz9cM3gigl r7yd1qiZoDCvHVStWNwQuqz1Y9vgtYWeAf8o8CrR5k8uyKdu3Athv8/IQ1uj9NN51w c2QKK/6vBJ9Iw== Received: from johan by xi.lan with local (Exim 4.98.2) (envelope-from ) id 1vi8og-000000002Jb-1BIk; Tue, 20 Jan 2026 11:18:31 +0100 Date: Tue, 20 Jan 2026 11:18:30 +0100 From: Johan Hovold To: Bartosz Golaszewski Cc: Bartosz Golaszewski , Srinivas Kandagatla , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers Message-ID: References: <20260116-nvmem-unbind-v1-0-7bb401ab19a8@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Jan 19, 2026 at 01:43:01PM +0100, Bartosz Golaszewski wrote: > On Mon, Jan 19, 2026 at 12:22 PM Johan Hovold wrote: > > > > On Fri, Jan 16, 2026 at 12:01:07PM +0100, Bartosz Golaszewski wrote: > > > Nvmem is one of the subsystems vulnerable to object life-time issues. > > > The memory nvmem core dereferences is owned by nvmem providers which can > > > be unbound at any time and even though nvmem devices themselves are > > > reference-counted, there's no synchronization with the provider modules. > > > > > > This typically is not a problem because thanks to fw_devlink, consumers > > > get synchronously unbound before providers but it's enough to pass > > > fw_devlink=off over the command line, unbind the nvmem controller with > > > consumers still holding references to it and try to read/write in order > > > to see fireworks in the kernel log. > > > > Well, don't do that then. Only root can unbind drivers, and we have > > things like module references to prevent drivers from being unloaded > > while in use. > > That's a very weird argument. It roughly translates to: "There's an > issue that can crash the system but only root can trigger it so let's > never fix it". If that's how we work then why don't we allow root to > kill init with a signal? It's not weird at all. The cost associated with preventing *root* from using a foot gun may simply be too high for it to be worth it. For a regular user, the equation is different. > Is this a corner-case? Sure. Should we not address corner cases? Then > why do we fix error paths we never hit or that result in an unusable > system anyway? That's just a false equivalence. > Also: sysfs attributes don't take a module reference. Unloading an > nvmem module during a long read from user-space is equivalent to a USB > unplug. Sysfs will drain any ongoing operations before deregistering, so not sure what you're referring to here. > > > User-space can trigger it too if a device (for instance: i2c eeprom on a > > > cp2112 USB expander) is unplugged halfway through a long read. > > > > Hotplugging may be a real issue, though. But this can solved at the user > > interface level. Did you explore that? > > > > Did I explore what exactly? If you're saying this *can* be solved, > then please also say how. Nvmem has no idea what abstraction layer it > sits above. Nvmem core doesn't even know what abstraction layer the > nvmem providers use. The userspace interface for nvmem access. If the only interface is the sysfs one then there should be nothing to worry about there. > > For reference, this is related to the i2c discussion here: > > > > https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/ > > > > Your argument against the i2c changes is that they affect lots of > drivers and decrease readability. I can see it as a point worth > considering. In the end it's up to Wolfram to decide and I think he > was pretty clear he wants it to proceed. > > This series addresses the unbinding issue entirely within nvmem core, > no driver changes are required. It uses SRCU which is very fast in > read sections. What exactly is your argument against it? What is the > reason for your comment? Unless you deal with nvmem internals, you > never have to concern yourself with it. My concern is that you're stuck on the idea of wrapping every access in the kernel with unnecessary constructs because you seem to think driver unbinding is something we need to worry about it. It's not. At least not at any cost (readability, maintainability, cognitive load, churn, performance, ...). Johan