[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231018175347.67d5ccf4@kernel.org>
Date: Wed, 18 Oct 2023 17:53:47 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Ido Schimmel <idosch@...dia.com>
Cc: <netdev@...r.kernel.org>, <linux-pci@...r.kernel.org>,
<davem@...emloft.net>, <pabeni@...hat.com>, <edumazet@...gle.com>,
<bhelgaas@...gle.com>, <alex.williamson@...hat.com>, <lukas@...ner.de>,
<petrm@...dia.com>, <jiri@...dia.com>, <mlxsw@...dia.com>
Subject: Re: [RFC PATCH net-next 01/12] netdevsim: Block until all devices
are released
On Tue, 17 Oct 2023 10:42:46 +0300 Ido Schimmel wrote:
> Like other buses, devices on the netdevsim bus have a release callback
> that is invoked when the reference count of the device drops to zero.
> However, unlike other buses such as PCI, the release callback is not
> necessarily built into the kernel, as netdevsim can be built as a
> module.
>
> This above is problematic as nothing prevents the module from being
> unloaded before the release callback has been invoked, which can happen
> asynchronously. One such example is going to be added in subsequent
> patches where devlink will call put_device() from an RCU callback.
>
> The issue is not theoretical and the reproducer in [1] can reliably
> crash the kernel. The conclusion of this discussion was that the issue
> should be solved in netdevsim, which is what this patch is trying to do.
>
> Add a reference count that is increased when a device is added to the
> bus and decreased when a device is released. Signal a completion when
> the reference count drops to zero and wait for the completion when
> unloading the module so that the module will not be unloaded before all
> the devices were released. The reference count is initialized to one so
> that completion is only signaled when unloading the module.
>
> With this patch, the reproducer in [1] no longer crashes the kernel.
>
> [1] https://lore.kernel.org/netdev/20230619125015.1541143-2-idosch@nvidia.com/
>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
Reviewed-by: Jakub Kicinski <kuba@...nel.org>
Powered by blists - more mailing lists