From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Lorenz Bauer <lmb@cloudflare.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andriin@fb.com>,
kernel-team <kernel-team@cloudflare.com>
Subject: Re: Advisory file locking behaviour of bpf_link (and others?)
Date: Wed, 26 Aug 2020 11:22:49 +0200 [thread overview]
Message-ID: <87zh6hwyl2.fsf@toke.dk> (raw)
In-Reply-To: <CACAyw988=DLoXJ6dC4qkTCWgQu2M19fVTAhjnF5Hg2Oe=mkmOw@mail.gmail.com>
Lorenz Bauer <lmb@cloudflare.com> writes:
> On Tue, 25 Aug 2020 at 19:06, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Tue, Aug 25, 2020 at 6:39 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
>> >
>> > Hi,
>> >
>> > I was playing around a bit, and noticed that trying to acquire an
>> > exclusive POSIX record lock on a bpf_link fd fails. I've traced this
>> > to the call to anon_inode_getfile from bpf_link_prime which
>> > effectively specifies O_RDONLY on the bpf_link struct file. This makes
>> > check_fmode_for_setlk return EBADF.
>> >
>> > This means the following:
>> > * flock(link, LOCK_EX): works
>> > * fcntl(link, SETLK, F_RDLCK): works
>> > * fcntl(link, SETLK, F_WRLCK): doesn't work
>> >
>> > Especially the discrepancy between flock(EX) and fcntl(WRLCK) has me
>> > puzzled. Should fcntl(WRLCK) work on a link?
>> >
>> > program fds are always O_RDWR as far as I can tell (so all locks
>> > work), while maps depend on map_flags.
>>
>> Because for links fd/file flags are reserved for the future use.
>> progs are rdwr for historical reasons while maps can have three combinations:
>> /* Flags for accessing BPF object from syscall side. */
>> BPF_F_RDONLY = (1U << 3),
>> BPF_F_WRONLY = (1U << 4),
>> by default they are rdwr.
>> What is your use case to use flock on bpf_link fd?
>
> The idea is to prevent concurrent access / modification of pinned maps
> + pinned link from a command line tool. I could just as well lock one
> of the maps for this, but conceptually the link is the thing that
> actually controls what maps are used via the attached BPF program.
> FWIW I'm using flock(EX) on the link for now, which is fine for my use
> case. I just thought I'd raise this in case it was an oversight :)
FWIW I'm doing something similar in libxdp, except I'm using flock(EX)
on the parent directory (i.e., /sys/fs/bpf/xdp) since I need to protect
multiple modifications inside it:
https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/libxdp.c#L245
-Toke
next prev parent reply other threads:[~2020-08-26 9:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 13:38 Advisory file locking behaviour of bpf_link (and others?) Lorenz Bauer
2020-08-25 18:06 ` Alexei Starovoitov
2020-08-26 7:50 ` Lorenz Bauer
2020-08-26 9:22 ` Toke Høiland-Jørgensen [this message]
2020-08-26 13:32 ` Lorenz Bauer
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=87zh6hwyl2.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@cloudflare.com \
--cc=lmb@cloudflare.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox