[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26b3858e-6e5e-d782-118b-c4d64e2532f2@tessares.net>
Date: Mon, 1 Mar 2021 16:04:13 +0100
From: Matthieu Baerts <matthieu.baerts@...sares.net>
To: Chuck Lever <chuck.lever@...cle.com>,
syzbot <syzbot+e2fa57709a385e6db10f@...kaller.appspotmail.com>
Cc: Bruce Fields <bfields@...ldses.org>,
"David S. Miller" <davem@...emloft.net>,
"dsahern@...nel.org" <dsahern@...nel.org>,
Jakub Kicinski <kuba@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
Linux-Net <netdev@...r.kernel.org>,
"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
MPTCP Upstream <mptcp@...ts.01.org>
Subject: Re: possible deadlock in ipv6_sock_mc_close
Hi Chuck,
(+ cc: MPTCP list)
On 01/03/2021 15:52, Chuck Lever wrote:
>> On Mar 1, 2021, at 8:49 AM, syzbot <syzbot+e2fa57709a385e6db10f@...kaller.appspotmail.com> wrote:
(...)
>> syzbot found the following issue on:
(...)
> Hi, thanks for the report.
>
> Initial analysis:
>
> c8e88e3aa738 ("NFSD: Replace READ* macros in nfsd4_decode_layoutget()"
> changes code several layers above the network layer. In addition,
> neither of the stack traces contain NFSD functions. And, repro.c does
> not appear to exercise any filesystem code.
>
> Therefore the bisect result looks implausible to me. I don't see any
> obvious connection between the lockdep splat and c8e88e3aa738. (If
> someone else does, please let me know where to look).
From what I can see from the bisect logs, it looks like this issue is
difficult to reproduce. But it really looks like the issue is on MPTCP
side and not directly related to your patch.
Thanks to the syzbot team for reporting this!
It doesn't look very simple to fix but we are tracking this on our side:
https://github.com/multipath-tcp/mptcp_net-next/issues/170
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
Powered by blists - more mailing lists