From: Jakub Sitnicki <jakub@cloudflare.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: alexei.starovoitov@gmail.com, daniel@iogearbox.net,
netdev@vger.kernel.org, bpf@vger.kernel.org, lmb@cloudflare.com
Subject: Re: [bpf-next PATCH v3 4/6] bpf, sockmap: remove dropped data on errors in redirect case
Date: Tue, 13 Oct 2020 12:27:31 +0200 [thread overview]
Message-ID: <87d01mqv3g.fsf@cloudflare.com> (raw)
In-Reply-To: <5f84903d914d1_370c208c3@john-XPS-13-9370.notmuch>
On Mon, Oct 12, 2020 at 07:19 PM CEST, John Fastabend wrote:
> Jakub Sitnicki wrote:
>> On Fri, Oct 09, 2020 at 08:37 PM CEST, John Fastabend wrote:
>> > In the sk_skb redirect case we didn't handle the case where we overrun
>> > the sk_rmem_alloc entry on ingress redirect or sk_wmem_alloc on egress.
>> > Because we didn't have anything implemented we simply dropped the skb.
>> > This meant data could be dropped if socket memory accounting was in
>> > place.
>> >
>> > This fixes the above dropped data case by moving the memory checks
>> > later in the code where we actually do the send or recv. This pushes
>> > those checks into the workqueue and allows us to return an EAGAIN error
>> > which in turn allows us to try again later from the workqueue.
>> >
>> > Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path")
>> > Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> > ---
>> > net/core/skmsg.c | 28 ++++++++++++++--------------
>> > 1 file changed, 14 insertions(+), 14 deletions(-)
>> >
>>
>> [...]
>>
>> > @@ -709,30 +711,28 @@ static void sk_psock_skb_redirect(struct sk_buff *skb)
>> > {
>> > struct sk_psock *psock_other;
>> > struct sock *sk_other;
>> > - bool ingress;
>> >
>> > sk_other = tcp_skb_bpf_redirect_fetch(skb);
>> > + /* This error is a buggy BPF program, it returned a redirect
>> > + * return code, but then didn't set a redirect interface.
>> > + */
>> > if (unlikely(!sk_other)) {
>> > kfree_skb(skb);
>> > return;
>> > }
>> > psock_other = sk_psock(sk_other);
>> > + /* This error indicates the socket is being torn down or had another
>> > + * error that caused the pipe to break. We can't send a packet on
>> > + * a socket that is in this state so we drop the skb.
>> > + */
>> > if (!psock_other || sock_flag(sk_other, SOCK_DEAD) ||
>> > !sk_psock_test_state(psock_other, SK_PSOCK_TX_ENABLED)) {
>> > kfree_skb(skb);
>> > return;
>> > }
>> >
>> > - ingress = tcp_skb_bpf_ingress(skb);
>> > - if ((!ingress && sock_writeable(sk_other)) ||
>> > - (ingress &&
>> > - atomic_read(&sk_other->sk_rmem_alloc) <=
>> > - sk_other->sk_rcvbuf)) {
>>
>> I'm wondering why the check for going over socket's rcvbuf was removed?
>
> Couple reasons, I never checked it from skmsg side so after this patch
> accounting for both skmsg and sk_skb types are the same. I think this
> should be the case going forward with anything we do around memory
> accounting. The other, and more immediate, reason is we don't want the
> error case here with the kfree_skb().
Right, we definitely don't want to drop the skb.
What crossed my mind is that sk_psock_handle_skb() could check for
sk_rmem_alloc <= sk_rcvbuf and error out with -EAGAIN. Similarly to how
we check for sock_writable() with this change.
This would let the process owning the destination socket, we are
redirecting to, to push back by tuning down SO_RCVBUF.
>
>>
>> I see that we now rely exclusively on
>> sk_psock_skb_ingress→sk_rmem_schedule for sk_rmem_alloc checks, which I
>> don't think applies the rcvbuf limit.
>
> Right. Also notice even though we checked it here we never charged the
> skm_rmem_alloc for skmsg on the ingress queue. So we were effectively
> getting that memory for free. Still doing some review and drafting a
> patch to see if this works, but my proposal is:
>
> For ingress sk_skb case we check sk_rmem_alloc before enqueuing
> the new sk_msg into ingress queue and then also charge the memory
> the same as skb_set_owner_r except do it with a new helper
> skmsg_set_owner_r(skmsg, sk) and only do the atomic add against
> sk_rmem_alloc and the sk_mem_charge() part.
>
> Then for skmsg programs convert the sk_mem_charge() calls to
> use the new skmsg_set_owner_r() to get the same memory accounting.
> Finally, on copy to user buffer we unwind this. Then we will have
> the memory in the queue accounted for against the socket.
>
> I'll give it a try. Thanks for asking. wdyt? Any other ideas.
SGTM, nothing to add except for honoring SO_RCVBUF I mentioned above.
[...]
next prev parent reply other threads:[~2020-10-13 10:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 18:35 [bpf-next PATCH v2 0/6] sockmap/sk_skb program memory acct fixes John Fastabend
2020-10-09 18:36 ` [bpf-next PATCH v3 1/6] bpf, sockmap: skb verdict SK_PASS to self already checked rmem limits John Fastabend
2020-10-09 18:36 ` [bpf-next PATCH v3 2/6] bpf, sockmap: On receive programs try to fast track SK_PASS ingress John Fastabend
2020-10-12 9:03 ` Jakub Sitnicki
2020-10-12 15:33 ` John Fastabend
2020-10-13 19:43 ` Jakub Sitnicki
2020-10-09 18:36 ` [bpf-next PATCH v3 3/6] bpf, sockmap: remove skb_set_owner_w wmem will be taken later from sendpage John Fastabend
2020-10-09 18:37 ` [bpf-next PATCH v3 4/6] bpf, sockmap: remove dropped data on errors in redirect case John Fastabend
2020-10-12 12:04 ` Jakub Sitnicki
2020-10-12 17:19 ` John Fastabend
2020-10-13 10:27 ` Jakub Sitnicki [this message]
2020-10-09 18:37 ` [bpf-next PATCH v3 5/6] bpf, sockmap: Remove skb_orphan and let normal skb_kfree do cleanup John Fastabend
2020-10-09 18:37 ` [bpf-next PATCH v3 6/6] bpf, sockmap: Add memory accounting so skbs on ingress lists are visible John Fastabend
2020-10-12 1:10 ` [bpf-next PATCH v2 0/6] sockmap/sk_skb program memory acct fixes patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d01mqv3g.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).