mbox series

[bpf-next,0/2] Support RENAME_EXCHANGE on bpffs

Message ID 20211020082956.8359-1-lmb@cloudflare.com (mailing list archive)
Headers show
Series Support RENAME_EXCHANGE on bpffs | expand

Message

Lorenz Bauer Oct. 20, 2021, 8:29 a.m. UTC
Add support for renameat2(RENAME_EXCHANGE) on bpffs. This is useful
for atomic upgrades of our sk_lookup control plane.

* Create a temporary directory on bpffs
* Migrate maps and pin them into temporary directory
* Load new sk_lookup BPF, attach it and pin the link into temp dir
* renameat2(temp dir, state dir, RENAME_EXCHANGE)
* rmdir temp dir

Due to the sk_lookup semantics this means we can never end up in a
situation where an upgrade breaks the existing control plane.

Lorenz Bauer (2):
  libfs: support RENAME_EXCHANGE in simple_rename()
  selftests: bpf: test RENAME_EXCHANGE and RENAME_NOREPLACE on bpffs

 fs/libfs.c                                    |  6 ++-
 .../selftests/bpf/prog_tests/test_bpffs.c     | 39 +++++++++++++++++++
 2 files changed, 44 insertions(+), 1 deletion(-)

Comments

Alexei Starovoitov Oct. 21, 2021, 12:14 a.m. UTC | #1
On Wed, Oct 20, 2021 at 09:29:54AM +0100, Lorenz Bauer wrote:
> Add support for renameat2(RENAME_EXCHANGE) on bpffs. This is useful
> for atomic upgrades of our sk_lookup control plane.
> 
> * Create a temporary directory on bpffs
> * Migrate maps and pin them into temporary directory
> * Load new sk_lookup BPF, attach it and pin the link into temp dir
> * renameat2(temp dir, state dir, RENAME_EXCHANGE)
> * rmdir temp dir
> 
> Due to the sk_lookup semantics this means we can never end up in a
> situation where an upgrade breaks the existing control plane.

That is a cool idea.
The selftest doesn't exercise all of this logic.
It's only testing that RENAME_EXCHANGE works on directories within bpffs.
Do we need a test for other types of paths?