All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@fomichev.me>
To: Andrey Ignatov <rdna@fb.com>
Cc: Stanislav Fomichev <sdf@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	edumazet@google.com
Subject: Re: [PATCH bpf-next 0/5] add bpf cgroup hooks that trigger on socket close
Date: Fri, 18 Jan 2019 08:50:33 -0800	[thread overview]
Message-ID: <20190118165033.GA26773@mini-arch> (raw)
In-Reply-To: <20190118023654.GB8342@rdna-mbp.dhcp.thefacebook.com>

On 01/18, Andrey Ignatov wrote:
> Stanislav Fomichev <sdf@google.com> [Thu, 2019-01-17 16:41 -0800]:
> > Currently, we have BPF_CGROUP_INET_SOCK_CREATE hook that triggers on
> > socket creation and there is no way to know when the socket is being
> > closed. Add new set of hooks BPF_CGROUP_INET{4,6}_SOCK_RELEASE
> > that trigger when the socket is closed.
> > 
> > Initial intended usecase is to cleanup statistics after POST{4,6}_BIND.
> > Hooks have read-only access to all fields of struct bpf_sock.
> 
> Do you need it for both TCP and UDP?
Yes, we need both TCP and UDP. Although, UDP is tricky in general with
the connected/unconnected cases.

> I was thinking about this hook earlier but since in my case only TCP was
> needed I ended up using TCP-BPF. E.g. be BPF_SOCK_OPS_TCP_LISTEN_CB or
> BPF_SOCK_OPS_TCP_CONNECT_CB can be used instead of POST{4,6}_BIND to
> enable something, and then BPF_SOCK_OPS_STATE_CB can be used instead of
> SOCK_RELEASE to disable that something when socket transisions to
> BPF_TCP_CLOSE (e.g. BPF_TCP_LISTEN -> BPF_TCP_CLOSE).
> 
> That turned out to be much cleaner than POST{4,6}_BIND and also works
> fine when socket is disconnected with AF_UNSPEC and then connected again
> (what Eric mentioned).

What if we do something like the patch below? Add pre_release hook (like we
currently have for pre_connect) and call it from connect(AF_UNSPEC) and
from inet_release? Any concerns here?

(I agree that TCP is probably better handled via BPF_SOCK_OPS_TCP_XYZ hooks,
but we need something for UDP as well)

-- 

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index b703ad242365..ee3dc181df8f 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -568,8 +568,11 @@ int inet_dgram_connect(struct socket *sock, struct sockaddr *uaddr,
 
        if (addr_len < sizeof(uaddr->sa_family))
                return -EINVAL;
-       if (uaddr->sa_family == AF_UNSPEC)
+       if (uaddr->sa_family == AF_UNSPEC) {
+               if (BPF_CGROUP_PRE_RELEASE_ENABLED(sk))
+                       sk->sk_prot->pre_release(sk);
                return sk->sk_prot->disconnect(sk, flags);
+       }
 
        if (BPF_CGROUP_PRE_CONNECT_ENABLED(sk)) {
                err = sk->sk_prot->pre_connect(sk, uaddr, addr_len);
@@ -632,6 +635,8 @@ int __inet_stream_connect(struct socket *sock, struct sockaddr *uaddr,
                        return -EINVAL;
 
                if (uaddr->sa_family == AF_UNSPEC) {
+                       if (BPF_CGROUP_PRE_RELEASE_ENABLED(sk))
+                               sk->sk_prot->pre_release(sk);
                        err = sk->sk_prot->disconnect(sk, flags);
                        sock->state = err ? SS_DISCONNECTING : SS_UNCONNECTED;
                        goto out; 

> > First patch adds hooks, the rest of the patches add uapi and tests to make
> > sure these hooks work.
> > 
> > Stanislav Fomichev (5):
> >   bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE hooks
> >   tools: bpf: support BPF_CGROUP_INET{4,6}_SOCK_RELEASE in
> >     libbpf/bpftool
> >   selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to
> >     test_section_names.c
> >   selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to test_sock.c
> >   selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to
> >     test_sock_addr.c
> > 
> >  include/linux/bpf-cgroup.h                    |   6 +
> >  include/net/inet_common.h                     |   1 +
> >  include/uapi/linux/bpf.h                      |   2 +
> >  kernel/bpf/syscall.c                          |   8 ++
> >  net/core/filter.c                             |   7 +
> >  net/ipv4/af_inet.c                            |  13 +-
> >  net/ipv6/af_inet6.c                           |   5 +-
> >  tools/bpf/bpftool/cgroup.c                    |   2 +
> >  tools/include/uapi/linux/bpf.h                |   2 +
> >  tools/lib/bpf/libbpf.c                        |   4 +
> >  .../selftests/bpf/test_section_names.c        |  10 ++
> >  tools/testing/selftests/bpf/test_sock.c       | 119 ++++++++++++++++
> >  tools/testing/selftests/bpf/test_sock_addr.c  | 131 +++++++++++++++++-
> >  13 files changed, 307 insertions(+), 3 deletions(-)
> > 
> > -- 
> > 2.20.1.321.g9e740568ce-goog
> > 
> 
> -- 
> Andrey Ignatov

  reply	other threads:[~2019-01-18 16:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18  0:41 [PATCH bpf-next 0/5] add bpf cgroup hooks that trigger on socket close Stanislav Fomichev
2019-01-18  0:41 ` [PATCH bpf-next 1/5] bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE hooks Stanislav Fomichev
2019-01-18  2:22   ` Andrey Ignatov
2019-01-18  6:30   ` kbuild test robot
2019-01-18  7:23   ` kbuild test robot
2019-01-18  0:41 ` [PATCH bpf-next 2/5] tools: bpf: support BPF_CGROUP_INET{4,6}_SOCK_RELEASE in libbpf/bpftool Stanislav Fomichev
2019-01-18  0:41 ` [PATCH bpf-next 3/5] selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to test_section_names.c Stanislav Fomichev
2019-01-18  0:41 ` [PATCH bpf-next 4/5] selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to test_sock.c Stanislav Fomichev
2019-01-18  0:41 ` [PATCH bpf-next 5/5] selftests/bpf: add BPF_CGROUP_INET{4,6}_SOCK_RELEASE to test_sock_addr.c Stanislav Fomichev
2019-01-18  2:45   ` Andrey Ignatov
2019-01-18  1:02 ` [PATCH bpf-next 0/5] add bpf cgroup hooks that trigger on socket close Eric Dumazet
2019-01-18  1:58   ` Stanislav Fomichev
2019-01-18  2:36 ` Andrey Ignatov
2019-01-18 16:50   ` Stanislav Fomichev [this message]
2019-01-18 22:39     ` Andrey Ignatov
2019-01-22 17:00       ` Stanislav Fomichev

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=20190118165033.GA26773@mini-arch \
    --to=sdf@fomichev.me \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.com \
    --cc=sdf@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.