From: "Toke Høiland-Jørgensen" <email@example.com> To: Andrii Nakryiko <firstname.lastname@example.org> Cc: Daniel Borkmann <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>, Martin KaFai Lau <email@example.com>, Song Liu <firstname.lastname@example.org>, Yonghong Song <email@example.com>, Jesper Dangaard Brouer <firstname.lastname@example.org>, David Miller <email@example.com>, Networking <firstname.lastname@example.org>, bpf <email@example.com> 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: <firstname.lastname@example.org> (raw) In-Reply-To: <CAEf4Bzap3oMPnGJQAsoV-g77ux0FdELiJpvpxn9_zadVnHYdSA@mail.gmail.com> Andrii Nakryiko <email@example.com> writes: > On Tue, Oct 22, 2019 at 12:04 PM Toke Høiland-Jørgensen <firstname.lastname@example.org> wrote: >> >> Andrii Nakryiko <email@example.com> writes: >> >> > On Tue, Oct 22, 2019 at 9:08 AM Toke Høiland-Jørgensen <firstname.lastname@example.org> wrote: >> >> >> >> From: Toke Høiland-Jørgensen <email@example.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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH bpf-next 3/3] libbpf: Add pin option to automount BPF filesystem before pinning' \ /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
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).