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 AB3673101DB for ; Mon, 19 Jan 2026 11:22:23 +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=1768821743; cv=none; b=ADoqH4qV63UeqxXwYrPDcWnjJ2ByyQMEWW9+LKtKAshCiH3rYTWEaLQXvajGZQxbN3FfkWpovaMkfWYTN6v6w1q5KwKs7d93nTM0I1KU+15tteM6nbZ81ZPYOjCYMRj1maWoaVkRRpOY6h3o9tKZGmC+Fsea4kSgDU0nmAq+DXc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768821743; c=relaxed/simple; bh=LVw1nfZZHVq4o50b83dQjYyv1L4pCNvNHd9S8XUd4EY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=szJ2f61IfoVLpvT4rEERWd3bfYoOAwWUtMbAuU4q1l3xM21UkuBoSQjmixSqs/n2PtqbapOpCjw4gvpUTLtvNeLxEOICvQYligD1ldMttpxFV+EaGf9MYdGBoIWJW8N/+JgZgIG+vM2NDkZy/RHijvgjhTRhqSICnigAlBtyqpo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HwUg+A4T; 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="HwUg+A4T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B126C116C6; Mon, 19 Jan 2026 11:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768821743; bh=LVw1nfZZHVq4o50b83dQjYyv1L4pCNvNHd9S8XUd4EY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HwUg+A4TpxYAqPkaVnfmPSNjJEKJtj5zyd1VLDZWfR02xNerT89BOUgnoGhdQ+ei+ OutQ+XS4i7gV2T/uLImFJdR+HtBJUP3dQYb1H5pWnXTfnlizVbFo17Fse+BDyqyzQA T+LMAzNQI1IHpaZIUY90WGNJ8pGpBVXWjQ76/C4e7rjhE0dFB/xerPIJuYnuIN8JWi y+ud1R4vGdkNtOufiO/IRC8ki596zxhRh/iebcH7+p9V1B2M1gBdpdBxXv9Z+mE6I8 DpcSsaR/EMOIwda8uQKq2uDYr7iiURHkq5KTsGXjZ1xjh8cm/uKGO/ZDjQ1d+ppI3u wPVqK35VtaN7g== Received: from johan by xi.lan with local (Exim 4.98.2) (envelope-from ) id 1vhnKp-000000001AG-3yDI; Mon, 19 Jan 2026 12:22:16 +0100 Date: Mon, 19 Jan 2026 12:22:15 +0100 From: Johan Hovold To: Bartosz Golaszewski Cc: Srinivas Kandagatla , Bartosz Golaszewski , 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=us-ascii Content-Disposition: inline In-Reply-To: <20260116-nvmem-unbind-v1-0-7bb401ab19a8@oss.qualcomm.com> 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. > 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? For reference, this is related to the i2c discussion here: https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/ Johan