[bpf-next PATCH 1/2] bpf: sockmap, free memory on sock close with cork data

[bpf-next PATCH 1/2] bpf: sockmap, free memory on sock close with cork data

[John Fastabend]

If a socket with pending cork data is closed we do not return the
memory to the socket until the garbage collector free's the psock
structure. The garbage collector though can run after the sock has
completed its close operation. If this ordering happens the sock code
will through a WARN_ON because there is still outstanding memory
accounted to the sock.

To resolve this ensure we return memory to the sock when a socket
is closed.

Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Fixes: 91843d540a13 ("bpf: sockmap, add msg_cork_bytes() helper")
---
 kernel/bpf/sockmap.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index d2bda5a..8ddf326 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -211,6 +211,12 @@ static void bpf_tcp_close(struct sock *sk, long timeout)
 	close_fun = psock->save_close;
 
 	write_lock_bh(&sk->sk_callback_lock);
+	if (psock->cork) {
+		free_start_sg(psock->sock, psock->cork);
+		kfree(psock->cork);
+		psock->cork = NULL;
+	}
+
 	list_for_each_entry_safe(md, mtmp, &psock->ingress, list) {
 		list_del(&md->list);
 		free_start_sg(psock->sock, md);

[bpf-next PATCH 2/2] bpf: sockmap, duplicates release calls may NULL sk_prot

[John Fastabend]

It is possible to have multiple ULP tcp_release call paths in flight
if a sock is closed and simultaneously being removed from the sockmap
control path. The result would be setting the sk_prot to the saved
values on the first iteration and then on the second iteration setting
the value to NULL.

This patch resolves this by ensuring we only reset the sk_prot pointer
if we have a valid saved state to set.

Fixes: 4f738adba30a7 ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 kernel/bpf/sockmap.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 8ddf326..8dd9210 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -182,8 +182,10 @@ static void bpf_tcp_release(struct sock *sk)
 		psock->cork = NULL;
 	}
 
-	sk->sk_prot = psock->sk_proto;
-	psock->sk_proto = NULL;
+	if (psock->sk_proto) {
+		sk->sk_prot = psock->sk_proto;
+		psock->sk_proto = NULL;
+	}
 out:
 	rcu_read_unlock();
 }

Re: [bpf-next PATCH 1/2] bpf: sockmap, free memory on sock close with cork data

[John Fastabend]

On 04/02/2018 12:50 PM, John Fastabend wrote:
> If a socket with pending cork data is closed we do not return the
> memory to the socket until the garbage collector free's the psock
> structure. The garbage collector though can run after the sock has
> completed its close operation. If this ordering happens the sock code
> will through a WARN_ON because there is still outstanding memory
> accounted to the sock.
> 
> To resolve this ensure we return memory to the sock when a socket
> is closed.
> 
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> Fixes: 91843d540a13 ("bpf: sockmap, add msg_cork_bytes() helper")
> ---

Hi Alexei, Daniel,

These two fixes apply against current bpf-next or bpf after
bpf-next is merged. I could resend later I suppose but I think
it makes sense to get these in sooner rather than later. 

Thanks,
John

Re: [bpf-next PATCH 1/2] bpf: sockmap, free memory on sock close with cork data

[Daniel Borkmann]

On 04/02/2018 09:58 PM, John Fastabend wrote:
> On 04/02/2018 12:50 PM, John Fastabend wrote:
>> If a socket with pending cork data is closed we do not return the
>> memory to the socket until the garbage collector free's the psock
>> structure. The garbage collector though can run after the sock has
>> completed its close operation. If this ordering happens the sock code
>> will through a WARN_ON because there is still outstanding memory
>> accounted to the sock.
>>
>> To resolve this ensure we return memory to the sock when a socket
>> is closed.
>>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> Fixes: 91843d540a13 ("bpf: sockmap, add msg_cork_bytes() helper")
>> ---
> 
> Hi Alexei, Daniel,
> 
> These two fixes apply against current bpf-next or bpf after
> bpf-next is merged. I could resend later I suppose but I think
> it makes sense to get these in sooner rather than later. 

Applied to bpf tree, thanks John!