[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALye=_-oqMO-LRWd7pvMUnOxDCNVg0v=Wgmg8Qggg1Q3yL-jmQ@mail.gmail.com>
Date: Fri, 7 Jun 2024 14:09:59 +0200
From: Vincent Whitchurch <vincent.whitchurch@...adoghq.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: John Fastabend <john.fastabend@...il.com>, Jakub Sitnicki <jakub@...udflare.com>,
Jason Xing <kernelxing@...cent.com>, netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: Recursive locking in sockmap
On Thu, Jun 6, 2024 at 2:47 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> On Thu, Jun 6, 2024 at 6:00 PM Vincent Whitchurch
> <vincent.whitchurch@...adoghq.com> wrote:
> > With a socket in the sockmap, if there's a parser callback installed
> > and the verdict callback returns SK_PASS, the kernel deadlocks
> > immediately after the verdict callback is run. This started at commit
> > 6648e613226e18897231ab5e42ffc29e63fa3365 ("bpf, skmsg: Fix NULL
> > pointer dereference in sk_psock_skb_ingress_enqueue").
> >
> > It can be reproduced by running ./test_sockmap -t ping
> > --txmsg_pass_skb. The --txmsg_pass_skb command to test_sockmap is
> > available in this series:
> > https://lore.kernel.org/netdev/20240606-sockmap-splice-v1-0-4820a2ab14b5@datadoghq.com/.
>
> I don't have time right now to look into this issue carefully until
> this weekend. BTW, did you mean the patch [2/5] in the link that can
> solve the problem?
No. That patch set addresses a different problem which occurs even if
only a verdict callback is used. But patch 4/5 in that patch set adds
the --txmsg_pass_skb option to the test_sockmap test program, and that
option can be used to reproduce this deadlock too.
Powered by blists - more mailing lists