On Wed, 2023-10-11 at 08:43 +0200, Marc Kleine-Budde wrote:
On 11.10.2023 00:21:31, Francois Romieu wrote:
Marc Kleine-Budde mkl@pengutronix.de :
The dm9000 takes the db->lock spin lock in dm9000_timeout() and calls into dm9000_init_dm9000(). For the DM9000B the PHY is reset with dm9000_phy_write(). That function again takes the db->lock spin lock, which results in a deadlock. For reference the backtrace:
[...]
To workaround similar problem (take mutex inside spin lock ) , a "in_timeout" variable was added in 582379839bbd ("dm9000: avoid sleeping in dm9000_timeout callback"). Use this variable and not take the spin lock inside dm9000_phy_write() if in_timeout is true.
Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde mkl@pengutronix.de
During the netdev watchdog handling the dm9000 driver takes the same spin lock twice. Avoid this by extending an existing workaround.
I can review it but I can't really endorse it. :o)
Extending ugly workaround in pre-2000 style device drivers... I'd rather see the thing fixed if there is some real use for it.
There definitely are still users of this drivers on modern kernels out there.
I too don't like the feeling of wrapping more and more duct tape around existing drivers. How about moving the functionality to dm9000_phy_write_locked() and leave the locking in dm9000_phy_write(). I will prepare a patch.
If you have the H/W handy to try some more invasive change, I'm wondering if you could schedule a work from dm9000_timeout() and there acquire all the needed locks.
Cheers,
Paolo