program lock requires writeable current working directory

Question

program lock requires writeable current working directory

dankamongmen opened this issue a year ago · comments

I'm using libxdp within a program launched from systemd, and getting errors trying to take the program lock (prog_lock_get(), lib/util/util.c). The directory I'm launched within is indeed not writeable (it is a readonly filesystem). I am using the libxdp API, not one of the user-facing tools.

Unless you have unique considerations, I'd recommend (in order of desirability):

(1) not having a program lock in a shared library. it's the application's job to mediate its own access to libxdp. the program lock as implemented obviously doesn't work for multiple applications anyway (which was presumably never its goal).
(2) if mutual exclusion is your only goal, use a mutex with static initialization
(3) using TMPDIR for the program lock

Toke Høiland-Jørgensen · Answer 1 · Sun Apr 09 2023 05:02:49 GMT+0800 (China Standard Time)

Are you sure those errors are coming from prog_lock_get()? libxdp doens't call that at all. However, libxdp *does* have its own locking mechanism, taking an an flock() on /sys/fs/bpf/xdp as described here: https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/protocol.org#locking-and-pinning So maybe you just need to make /sys/fs/bpf writable in your systemd unit config? libxdp requires access to this for pinning anyway...

nick black · Answer 2 · Mon Apr 10 2023 18:18:24 GMT+0800 (China Standard Time)

Are you sure those errors are coming from prog_lock_get()? libxdp doens't call that at all.

hrmm, no, i cannot state with certainty that i didn't see this from executing xdp-loader or something similar. with that said, this doesn't make sense to me there either, since its effectiveness depends on everyone launching the binary from the same working directory, no?

Toke Høiland-Jørgensen · Answer 3 · Mon Apr 10 2023 19:23:22 GMT+0800 (China Standard Time)

I'm not sure where you're getting the "working directory" thing from? The program lock is taken under RUNDIR, which defaults to /run - so if it's trying to take a lock in the current directory it's a bug in the build. Did you compile xdp-tools yourself?

nick black · Answer 4 · Mon Apr 10 2023 20:52:40 GMT+0800 (China Standard Time)

I'm not sure where you're getting the "working directory" thing from? The program lock is taken under RUNDIR, which defaults to /run - so if it's trying to take a lock in the current directory it's a bug in the build. Did you compile xdp-tools yourself?

you're of course correct that it's using RUNDIR; RUNDIR happened to be the working directory in my case, causing the confusion. my apologies.

so the bug, if it is that, is simply that if RUNDIR isn't writeable, the program fails. which i suppose is an administration failure -- RUNDIR must be writable. with that said, it prohibits some systemd protections from being applied. would it not be possible to use /sys/fs/bpf/xdp in all cases? i'll close this up regardless, and you can open it back up if you feel it to be appropriate.