[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJDVNqnMiGYHGQissykzASK-DcLss6LDAZetnp34n1gxw@mail.gmail.com>
Date: Fri, 2 Aug 2024 17:08:51 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Jeongjun Park <aha310510@...il.com>
Cc: jiri@...nulli.us, davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
syzbot+b668da2bc4cb9670bf58@...kaller.appspotmail.com
Subject: Re: [PATCH net,v2] team: fix possible deadlock in team_port_change_check
On Fri, Aug 2, 2024 at 5:00 PM Jeongjun Park <aha310510@...il.com> wrote:
>
> In do_setlink() , do_set_master() is called when dev->flags does not have
> the IFF_UP flag set, so 'team->lock' is acquired and dev_open() is called,
> which generates the NETDEV_UP event. This causes a deadlock as it tries to
> acquire 'team->lock' again.
>
> To fix this, we need to remove the unnecessary mutex_lock from all paths
> protected by rtnl. This patch also includes patches for paths that are
> already protected by rtnl and do not need the mutex_lock, in addition
> to the root cause reported.
>
> Reported-by: syzbot+b668da2bc4cb9670bf58@...kaller.appspotmail.com
> Fixes: 61dc3461b954 ("team: convert overall spinlock to mutex")
> Signed-off-by: Jeongjun Park <aha310510@...il.com>
> ---
This can not be right.
You have to completely remove team->lock, otherwise paths not taking
RTNL will race with ones holding RTNL.
Add ASSERT_RTNL() at the places we had a mutex_lock(&team->lock), and
see how it goes.
Powered by blists - more mailing lists