Thread (14 messages) 14 messages, 3 authors, 2021-05-21

Re: [Patch bpf] udp: fix a memory leak in udp_read_sock()

From: Cong Wang <hidden>
Date: 2021-05-18 21:22:00
Also in: bpf

On Tue, May 18, 2021 at 12:56 PM John Fastabend
[off-list ref] wrote:
Cong Wang wrote:
quoted
On Mon, May 17, 2021 at 10:36 PM John Fastabend
[off-list ref] wrote:
quoted
Cong Wang wrote:
quoted
From: Cong Wang <redacted>

sk_psock_verdict_recv() clones the skb and uses the clone
afterward, so udp_read_sock() should free the original skb after
done using it.
The clone only happens if sk_psock_verdict_recv() returns >0.
Sure, in case of error, no one uses the original skb either,
so still need to free it.
But the data is going to be dropped then. I'm questioning if this
is the best we can do or not. Its simplest sure, but could we
do a bit more work and peek those skbs or requeue them? Otherwise
if you cross memory limits for a bit your likely to drop these
unnecessarily.
What are the benefits of not dropping it? When sockmap takes
over sk->sk_data_ready() it should have total control over the skb's
in the receive queue. Otherwise user-space recvmsg() would race
with sockmap when they try to read the first skb at the same time,
therefore potentially user-space could get duplicated data (one via
recvmsg(), one via sockmap). I don't see any benefits but races here.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help