From: Alexei Starovoitov <ast@fb•com>
To: Andy Lutomirski <luto@amacapital•net>
Cc: "David S . Miller" <davem@davemloft•net>,
Daniel Borkmann <daniel@iogearbox•net>,
David Ahern <dsa@cumulusnetworks•com>,
Daniel Mack <daniel@zonque•org>, Tejun Heo <tj@kernel•org>,
Network Development <netdev@vger•kernel.org>
Subject: Re: [RFC PATCH net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag
Date: Fri, 10 Feb 2017 18:34:04 -0800 [thread overview]
Message-ID: <589E781C.3040909@fb.com> (raw)
In-Reply-To: <CALCETrVjLP+p1mk92h=Xy6EfQdC-dbYwzwHf_sCNzKNb8jeY-w@mail.gmail.com>
On 2/10/17 1:38 PM, Andy Lutomirski wrote:
> On Thu, Feb 9, 2017 at 10:59 AM, Alexei Starovoitov <ast@fb•com> wrote:
>> If BPF_F_ALLOW_OVERRIDE flag is used in BPF_PROG_ATTACH command
>> to the given cgroup the descendent cgroup will be able to override
>> effective bpf program that was inherited from this cgroup.
>> By default it's not passed, therefore override is disallowed.
>>
>> Examples:
>> 1.
>> prog X attached to /A with default
>> prog Y fails to attach to /A/B and /A/B/C
>> Everything under /A runs prog X
>>
>> 2.
>> prog X attached to /A with ALLOW_OVERRIDE
>> prog Y attached to /A/B with default. Everything under /A/B runs prog Y
>
> I think that, for ease of future extension, Y should also need
> ALLOW_OVERRIDE. Otherwise, when non-overridable hooks can stack,
> there could be confusion as to whether Y should override something or
> should stack.
I see. Fair enough. It's indeed easier for future extensions.
>> 2.
>> we can add another flag to reverse this call order too.
>> Instead of calling the progs from child to parent, do parent to child.
>
> I think the order should depend on the hook. Hooks for
> process-initiated actions (egress, socket creation) should run
> innermost first and hooks for outside actions (ingress) should be
> outermost first.
There are use cases where both ingress and egress
would want both ordering. Like the monitoring would want to
see the bytes that app wants to send and it would want
to see the bytes that it's actually sending. So if something
in the middle wants to drop due to whatever conditions,
the monitoring needs to be the first and the last in the prog chain.
That's one of the use cases for 'attach_priority'.
Some high priority can be reserved for debugging and so on.
>> Andy,
>> does it all make sense?
>
> Yes with the caveat above.
great!
>> Do you still insist on submitting this patch officially?
>
> I'm not sure what you mean.
it's an RFC. In netdev we never apply rfc patches.
>> or you're ok keeping it overridable for now.
>
> I really think the default should change for 4.10. People are going
fine. will respin with requested change.
prev parent reply other threads:[~2017-02-11 2:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 18:59 [RFC PATCH net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag Alexei Starovoitov
2017-02-10 18:22 ` Alexei Starovoitov
2017-02-10 21:38 ` Andy Lutomirski
2017-02-11 2:34 ` Alexei Starovoitov [this message]
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=589E781C.3040909@fb.com \
--to=ast@fb$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=daniel@zonque$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=dsa@cumulusnetworks$(echo .)com \
--cc=luto@amacapital$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tj@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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