[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <61781010b20b3_108a220859@john-XPS-13-9370.notmuch>
Date: Tue, 26 Oct 2021 07:26:24 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Liu Jian <liujian56@...wei.com>, john.fastabend@...il.com,
daniel@...earbox.net, jakub@...udflare.com, lmb@...udflare.com,
edumazet@...gle.com, davem@...emloft.net, yoshfuji@...ux-ipv6.org,
dsahern@...nel.org, kuba@...nel.org, ast@...nel.org,
andrii@...nel.org, kafai@...com, songliubraving@...com, yhs@...com,
kpsingh@...nel.org, netdev@...r.kernel.org, bpf@...r.kernel.org
Cc: liujian56@...wei.com
Subject: RE: [PATHC bpf v2] tcp_bpf: Fix one concurrency problem in the
tcp_bpf_send_verdict function
Liu Jian wrote:
> With two Msgs, msgA and msgB and a user doing nonblocking sendmsg calls (or
> multiple cores) on a single socket 'sk' we could get the following flow.
>
> msgA, sk msgB, sk
> ----------- ---------------
> tcp_bpf_sendmsg()
> lock(sk)
> psock = sk->psock
> tcp_bpf_sendmsg()
> lock(sk) ... blocking
> tcp_bpf_send_verdict
> if (psock->eval == NONE)
> psock->eval = sk_psock_msg_verdict
> ..
> < handle SK_REDIRECT case >
> release_sock(sk) < lock dropped so grab here >
> ret = tcp_bpf_sendmsg_redir
> psock = sk->psock
> tcp_bpf_send_verdict
> lock_sock(sk) ... blocking on B
> if (psock->eval == NONE) <- boom.
> psock->eval will have msgA state
>
> The problem here is we dropped the lock on msgA and grabbed it with msgB.
> Now we have old state in psock and importantly psock->eval has not been
> cleared. So msgB will run whatever action was done on A and the verdict
> program may never see it.
>
> Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
> Signed-off-by: Liu Jian <liujian56@...wei.com>
Yep thanks for digging into this. Nice catch. And commit looks good now.
Acked-by: John Fastabend <john.fastabend@...il.com>
Powered by blists - more mailing lists