From: Michal Kubiak <michal.kubiak@intel.com>
To: Jeongjun Park <aha310510@gmail.com>
Cc: <jiri@resnulli.us>,
<syzbot+705c61d60b091ef42c04@syzkaller.appspotmail.com>,
<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>, <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH net] team: Fix ABBA deadlock caused by race in team_del_slave
Date: Wed, 3 Jul 2024 17:18:36 +0200 [thread overview]
Message-ID: <ZoVrzGBouwEQU3Bu@localhost.localdomain> (raw)
In-Reply-To: <20240703145159.80128-1-aha310510@gmail.com>
On Wed, Jul 03, 2024 at 11:51:59PM +0900, Jeongjun Park wrote:
> CPU0 CPU1
> ---- ----
> lock(&rdev->wiphy.mtx);
> lock(team->team_lock_key#4);
> lock(&rdev->wiphy.mtx);
> lock(team->team_lock_key#4);
>
> Deadlock occurs due to the above scenario. Therefore,
> modify the code as shown in the patch below to prevent deadlock.
>
> Regards,
> Jeongjun Park.
The commit message should contain the patch description only (without
salutations, etc.).
>
> Reported-and-tested-by: syzbot+705c61d60b091ef42c04@syzkaller.appspotmail.com
> Fixes: 61dc3461b954 ("team: convert overall spinlock to mutex")
> Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> ---
> drivers/net/team/team_core.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
> index ab1935a4aa2c..3ac82df876b0 100644
> --- a/drivers/net/team/team_core.c
> +++ b/drivers/net/team/team_core.c
> @@ -1970,11 +1970,12 @@ static int team_add_slave(struct net_device *dev, struct net_device *port_dev,
> struct netlink_ext_ack *extack)
> {
> struct team *team = netdev_priv(dev);
> - int err;
> + int err, locked;
>
> - mutex_lock(&team->lock);
> + locked = mutex_trylock(&team->lock);
> err = team_port_add(team, port_dev, extack);
> - mutex_unlock(&team->lock);
> + if (locked)
> + mutex_unlock(&team->lock);
This is not correct usage of 'mutex_trylock()' API. In such a case you
could as well remove the lock completely from that part of code.
If "mutex_trylock()" returns false it means the mutex cannot be taken
(because it was already taken by other thread), so you should not modify
the resources that were expected to be protected by the mutex.
In other words, there is a risk of modifying resources using
"team_port_add()" by several threads at a time.
>
> if (!err)
> netdev_change_features(dev);
> @@ -1985,11 +1986,12 @@ static int team_add_slave(struct net_device *dev, struct net_device *port_dev,
> static int team_del_slave(struct net_device *dev, struct net_device *port_dev)
> {
> struct team *team = netdev_priv(dev);
> - int err;
> + int err, locked;
>
> - mutex_lock(&team->lock);
> + locked = mutex_trylock(&team->lock);
> err = team_port_del(team, port_dev);
> - mutex_unlock(&team->lock);
> + if (locked)
> + mutex_unlock(&team->lock);
The same story as in case of "team_add_slave()".
>
> if (err)
> return err;
> --
>
The patch does not seem to be a correct solution to remove a deadlock.
Most probably a synchronization design needs an inspection.
If you really want to use "mutex_trylock()" API, please consider several
attempts of taking the mutex, but never modify the protected resources when
the mutex is not taken successfully.
Thanks,
Michal
next prev parent reply other threads:[~2024-07-03 15:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 11:59 [syzbot] [net?] possible deadlock in team_del_slave (3) syzbot
2024-04-26 14:17 ` Hillf Danton
2024-07-03 14:51 ` [PATCH net] team: Fix ABBA deadlock caused by race in team_del_slave Jeongjun Park
2024-07-03 15:18 ` Michal Kubiak [this message]
2024-07-03 16:02 ` Jeongjun Park
2024-07-03 16:30 ` Eric Dumazet
2024-07-05 15:17 ` [syzbot] [net?] possible deadlock in team_del_slave (3) Jeongjun Park
2024-07-05 15:19 ` [PATCH net] team: Fix ABBA deadlock caused by race in team_del_slave Jeongjun Park
2024-07-04 10:15 ` [syzbot] [net?] possible deadlock in team_del_slave (3) Jiri Pirko
2024-07-06 4:13 ` [PATCH net,v2] team: Fix ABBA deadlock caused by race in team_del_slave Jeongjun Park
2024-07-06 15:01 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZoVrzGBouwEQU3Bu@localhost.localdomain \
--to=michal.kubiak@intel.com \
--cc=aha310510@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+705c61d60b091ef42c04@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox