linux: renameat2 flags support #12209

This allows for much cleaner VERIFY-level assertions. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support for ZoL, but the changes here allow for far nicer fallbacks than the previous implementation (the source and target are re-linked in case of the final link failing). In addition, a small cleanup was done for the "target exists but is a different type" codepath so that it's more understandable. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Implement support for Linux's RENAME_* flags (for renameat2). Aside from being quite useful for userspace (providing race-free ways to exchange paths and implement mv --no-clobber), they are used by overlayfs and are thus required in order to use overlayfs-on-ZFS. In order for us to represent the new renameat2(2) flags in the ZIL, we create two new transaction types for the two flags which need transactional-level support (RENAME_EXCHANGE and RENAME_WHITEOUT). RENAME_NOREPLACE does not need any ZIL support because we know that if the operation succeeded before creating the ZIL entry, there was no file to be clobbered and thus it can be treated as a regular TX_RENAME. As these new transaction flags modify the on-disk format, it is necessary to add feature flags (rename_exchange and rename_whiteout) -- two flags rather than one so that any future extensions to renameat2 can be handled consistently with another feature flag for the new feature. In order to reduce compatibility issues of pools between Linux (which supports these flags) and other operating systems (which currently don't), these feature flags are only activated once a new TX_RENAME_{EXCHANGE,WHITEOUT} is added to the ZIL and are deactivated when the ZIL is destroyed. This means that a cleanly exported pool can be imported onto a non-Linux system without issue (a pool with a ZIL log containing a new TX_RENAME_* entry can also be imported on such systems, but only in readonly mode). While this design is very similar to zilsaxattr, zilsaxattr is activated whenever the ZIL is instantiated (even if the new transaction type is never used) -- the rename_* feature flags are only activated when a new rename transaction is being added to the ZIL. Pavel helped with carrying this PR and reworking the ZIL bits after I originally wrote it, but the final version was effectively rewritten completely because the ZIL handling needed to be reworked entirely to be crash safe and to use feature flags. Cc: Pavel Snajdr <snajpa@snajpa.net> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

EL7 has backported renameat2(2) support, but this was done by creating a wrapper struct around the inode_operations struct and adding the rename2 callback to the wrapping struct. The semantics are the same as the upstream callback, so just detect and use the wrapper. Since we only need this wrapper for rename2 (and renaming is a directory operation) we only use the wrapper for the directory iops struct. Signed-off-by: Pavel Snajdr <snajpa@snajpa.net> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Since mv(1) doesn't expose the RENAME_* flags we need to have our own variation in the tests/ tree. The tests are fairly obvious functional tests, though in the future (once we solve the d_revalidate issue) we might also add a full-stack overlayfs integration test. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

linux: renameat2 flags support #12209

linux: renameat2 flags support #12209

Commits on Oct 11, 2022