[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b064ca33-1d94-4c7e-b0d0-78430d8cd0ac@intel.com>
Date: Mon, 2 Feb 2026 17:00:08 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Petr Oros <poros@...hat.com>
CC: <ivecera@...hat.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Andrew Lunn <andrew+netdev@...n.ch>, "Eric
Dumazet" <edumazet@...gle.com>, Stanislav Fomichev <sdf@...ichev.me>, "Tony
Nguyen" <anthony.l.nguyen@...el.com>, Przemek Kitszel
<przemyslaw.kitszel@...el.com>, <intel-wired-lan@...ts.osuosl.org>, "Paolo
Abeni" <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [Intel-wired-lan] [PATCH net] iavf: fix deadlock in reset
handling
On 2/2/2026 3:58 PM, Jakub Kicinski wrote:
> On Mon, 2 Feb 2026 09:48:20 +0100 Petr Oros wrote:
>> + netdev_unlock(netdev);
>> + ret = wait_event_interruptible_timeout(adapter->reset_waitqueue,
>> + !iavf_is_reset_in_progress(adapter),
>> + msecs_to_jiffies(5000));
>> + netdev_lock(netdev);
>
> Dropping locks taken by the core around the driver callback
> is obviously unacceptable. SMH.
Right. It seems like the correct fix is to either a) have reset take and
hold the netdev lock (now that its distinct from the global RTNL lock)
or b) refactor reset so that it can defer any of the netdev related
stuff somehow.
Powered by blists - more mailing lists