From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
David Miller <davem@davemloft.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 3/3] libbpf: Add pin option to automount BPF filesystem before pinning
Date: Wed, 23 Oct 2019 10:58:21 +0200 [thread overview]
Message-ID: <87o8y7n8ia.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4Bzap3oMPnGJQAsoV-g77ux0FdELiJpvpxn9_zadVnHYdSA@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Tue, Oct 22, 2019 at 12:04 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>>
>> > On Tue, Oct 22, 2019 at 9:08 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> >>
>> >> From: Toke Høiland-Jørgensen <toke@redhat.com>
>> >>
>> >> While the current map pinning functions will check whether the pin path is
>> >> contained on a BPF filesystem, it does not offer any options to mount the
>> >> file system if it doesn't exist. Since we now have pinning options, add a
>> >> new one to automount a BPF filesystem at the pinning path if that is not
>> >
>> > Next thing we'll be adding extra options to mount BPF FS... Can we
>> > leave the task of auto-mounting BPF FS to tools/applications?
>>
>> Well, there was a reason I put this into a separate patch: I wasn't sure
>> it really fit here. My reasoning is the following: If we end up with a
>> default auto-pinning that works really well, people are going to just
>> use that. And end up really confused when bpffs is not mounted. And it
>> seems kinda silly to make every application re-implement the same mount
>> check and logic.
>>
>> Or to put it another way: If we agree that the reasonable default thing
>> is to just pin things in /sys/fs/bpf, let's make it as easy as possible
>> for applications to do that right.
>>
>
> This reminds me the setrlimit() issue, though.
Heh, yeah. I personally consider the rlimit issue one of the top
usability issues with BPF :/
> And we decided that library shouldn't be manipulating global resources
> on behalf of users. I think this is a similar one.
Hmm, that's a fair point, actually. I do get twitchy watching most
applications just blindly setting rlimit to unlimited before they try to
load BPF programs...
I think I'll just drop this patch for now :)
-Toke
prev parent reply other threads:[~2019-10-23 8:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 15:04 [PATCH bpf-next 0/3] libbpf: Support pinning of maps using 'pinning' BTF attribute Toke Høiland-Jørgensen
2019-10-22 15:04 ` [PATCH bpf-next 1/3] libbpf: Store map pin path in struct bpf_map Toke Høiland-Jørgensen
2019-10-22 17:37 ` Andrii Nakryiko
2019-10-22 18:13 ` Toke Høiland-Jørgensen
2019-10-22 18:23 ` Andrii Nakryiko
2019-10-22 18:45 ` Toke Høiland-Jørgensen
2019-10-22 18:49 ` Andrii Nakryiko
2019-10-22 19:06 ` Toke Høiland-Jørgensen
2019-10-23 4:43 ` Andrii Nakryiko
2019-10-22 15:04 ` [PATCH bpf-next 2/3] libbpf: Support configurable pinning of maps from BTF annotations Toke Høiland-Jørgensen
2019-10-22 18:20 ` Andrii Nakryiko
2019-10-22 18:57 ` Toke Høiland-Jørgensen
2019-10-23 4:40 ` Andrii Nakryiko
2019-10-23 8:53 ` Toke Høiland-Jørgensen
2019-10-23 12:30 ` Daniel Borkmann
2019-10-23 13:05 ` Toke Høiland-Jørgensen
2019-10-22 15:04 ` [PATCH bpf-next 3/3] libbpf: Add pin option to automount BPF filesystem before pinning Toke Høiland-Jørgensen
2019-10-22 18:28 ` Andrii Nakryiko
2019-10-22 19:04 ` Toke Høiland-Jørgensen
2019-10-23 4:58 ` Andrii Nakryiko
2019-10-23 8:58 ` Toke Høiland-Jørgensen [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=87o8y7n8ia.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.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.