[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220310135901.39b1abdf@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Thu, 10 Mar 2022 13:59:01 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>
Cc: netdev@...r.kernel.org, Petr Oros <poros@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
intel-wired-lan@...ts.osuosl.org (moderated list:INTEL ETHERNET DRIVERS),
linux-kernel@...r.kernel.org (open list)
Subject: Re: [PATCH net] ice: Fix race condition during interface enslave
On Thu, 10 Mar 2022 18:16:41 +0100 Ivan Vecera wrote:
> Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating
> auxiliary device") changes a process of re-creation of aux device
> so ice_plug_aux_dev() is called from ice_service_task() context.
> This unfortunately opens a race window that can result in dead-lock
> when interface has left LAG and immediately enters LAG again.
>
> Reproducer:
> ```
> #!/bin/sh
>
> ip link add lag0 type bond mode 1 miimon 100
> ip link set lag0
>
> for n in {1..10}; do
> echo Cycle: $n
> ip link set ens7f0 master lag0
> sleep 1
> ip link set ens7f0 nomaster
> done
What's the priority on this one? The loop max of 10 seems a little
worrying.
Tony, Jesse, is it important enough to push into 5.17 or do you prefer
to take it via the normal path and do full QA? The blamed patch come
in to 5.17-rc it seems.
Powered by blists - more mailing lists