All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Sitnicki <jakub@cloudflare.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Alex Dewar <alex.dewar90@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Lorenz Bauer <lmb@cloudflare.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andrii@kernel.org>,
	KP Singh <kpsingh@chromium.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: sockmap: Don't call bpf_prog_put() on NULL pointer
Date: Thu, 15 Oct 2020 13:04:39 +0200	[thread overview]
Message-ID: <875z7brbqw.fsf@cloudflare.com> (raw)
In-Reply-To: <5f87d37225c32_b7602083@john-XPS-13-9370.notmuch>

On Thu, Oct 15, 2020 at 06:43 AM CEST, John Fastabend wrote:

[...]

> Jakub, any opinions on if we should just throw an error if users try to
> add a sock to a map with a parser but no verdict? At the moment we fall
> through and add the socket, but it wont do any receive parsing/verdict.
> At the moment I think its fine with above fix. The useful cases for RX
> are parser+verdict, verdict, and empty. Where empty is just used for
> redirects or other socket account tricks. Just something to keep in mind.

IMO we should not fail because map updates can interleave with sk_skb
prog attachments, like so:

	update_map(map_fd, sock_fd);
	attach_prog(parser_fd, map_fd, BPF_SK_SKB_STREAM_PARSER);
	update_map(map_fd, sock_fd); // OK
	attach_prog(verdict_fd, map_fd, BPF_SK_SKB_STREAM_VERDICT);
	update_map(map_fd, sock_fd);

In practice, I would expect one process/thread to attach the programs,
while another is allowed to update the map at the same time.

  reply	other threads:[~2020-10-15 11:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12 17:09 [PATCH] net: sockmap: Don't call bpf_prog_put() on NULL pointer Alex Dewar
2020-10-14  9:20 ` Jakub Sitnicki
2020-10-15  4:43   ` John Fastabend
2020-10-15 11:04     ` Jakub Sitnicki [this message]
2020-10-14  9:32 ` Jakub Sitnicki
2020-10-14  9:45   ` Alex Dewar
2020-10-15 19:10 ` 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=875z7brbqw.fsf@cloudflare.com \
    --to=jakub@cloudflare.com \
    --cc=alex.dewar90@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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.