- Linux-kselftest-mirror - lists.linaro.org

[PATCH v6 0/4] fat: add support for the renameat2 RENAME_EXCHANGE flag

by Javier Martinez Canillas

Hello, The series adds support for the renameat2 system call RENAME_EXCHANGE flag (which allows to atomically replace two paths) to the vfat filesystem code. There are many use cases for this, but we are particularly interested in making possible for vfat filesystems to be part of OSTree [0] deployments. Currently OSTree relies on symbolic links to make the deployment updates an atomic transactional operation. But RENAME_EXCHANGE could be used [1] to achieve a similar level of robustness when using a vfat filesystem. Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE support, patch #2 moves some code blocks in vfat_rename() to a set of helper functions, that can be reused by tvfat_rename_exchange() that's added by patch #3 and finally patch #4 adds some kselftests to test it. This is a v6 that addresses issues pointed out in v5: https://lkml.org/lkml/2022/6/9/361 [0]: https://github.com/ostreedev/ostree [1]: https://github.com/ostreedev/ostree/issues/1649 Changes in v6: - Simplify logic to determine if nlink have to modified (OGAWA Hirofumi). Changes in v5: - Only update nlink for different parent dirs and file types (OGAWA Hirofumi). Changes in v4: - Add new patch from OGAWA Hirofumi to use the helpers in vfat_rename(). - Rebase the patch on top of OGAWA Hirofumi proposed changes. - Drop iversion increment for old and new file inodes (OGAWA Hirofumi). - Add Muhammad Usama Anjum Acked-by tag. Changes in v3: - Add a .gitignore for the rename_exchange binary (Muhammad Usama Anjum). - Include $(KHDR_INCLUDES) instead of hardcoding a relative path in Makefile (Muhammad Usama Anjum). Changes in v2: - Only update the new_dir inode version and timestamps if != old_dir (Alex Larsson). - Add some helper functions to avoid duplicating code (OGAWA Hirofumi). - Use braces for multi-lines blocks even if are one statement (OGAWA Hirofumi). - Mention in commit message that the operation is as transactional as possible but within the vfat limitations of not having a journal (Colin Walters). - Call sync to flush the page cache before checking the file contents (Alex Larsson). - Drop RFC prefix since the patches already got some review. Javier Martinez Canillas (3): fat: add a vfat_rename2() and make existing .rename callback a helper fat: add renameat2 RENAME_EXCHANGE flag support selftests/filesystems: add a vfat RENAME_EXCHANGE test OGAWA Hirofumi (1): fat: factor out reusable code in vfat_rename() as helper functions MAINTAINERS | 1 + fs/fat/namei_vfat.c | 231 +++++++++++++++--- tools/testing/selftests/Makefile | 1 + .../selftests/filesystems/fat/.gitignore | 2 + .../selftests/filesystems/fat/Makefile | 7 + .../testing/selftests/filesystems/fat/config | 2 + .../filesystems/fat/rename_exchange.c | 37 +++ .../filesystems/fat/run_fat_tests.sh | 82 +++++++ 8 files changed, 324 insertions(+), 39 deletions(-) create mode 100644 tools/testing/selftests/filesystems/fat/.gitignore create mode 100644 tools/testing/selftests/filesystems/fat/Makefile create mode 100644 tools/testing/selftests/filesystems/fat/config create mode 100644 tools/testing/selftests/filesystems/fat/rename_exchange.c create mode 100755 tools/testing/selftests/filesystems/fat/run_fat_tests.sh -- 2.36.1

3 years

2
2
0 0

[PATCH v3 0/2] bpf: Add bpf_verify_signature() helper

by Roberto Sassu

One of the desirable features in security is the ability to restrict import of data to a given system based on data authenticity. If data import can be restricted, it would be possible to enforce a system-wide policy based on the signing keys the system owner trusts. This feature is widely used in the kernel. For example, if the restriction is enabled, kernel modules can be plugged in only if they are signed with a key whose public part is in the primary or secondary keyring. For eBPF, it can be useful as well. For example, it might be useful to authenticate data an eBPF program makes security decisions on. After a discussion in the eBPF mailing list, it was decided that the stated goal should be accomplished by introducing a new helper: bpf_verify_signature(). Its job is simply to call the signature verification function corresponding to the passed signature type, with the keyring selected through the passed keyring identifier. Since verify_pkcs7_signature() is doing crypto operations, it must be called by a sleepable program. This restricts the set of functions that can call the associated helper (for example, lsm.s/bpf is suitable, fexit/array_map_update_elem is not). The added test checks the ability of an eBPF program to verify module-style appended signatures, as produced by the kernel tool sign-file, currently used to sign kernel modules. The patch set is organized as follows. Patch 1 introduces the new helper. Patch 2 adds the test for the new helper. Changelog v1: - Don't define new map flag but introduce simple wrapper of verify_pkcs7_signature() (suggested by Alexei and KP) v2: - Rename bpf_verify_pkcs7_signature() to a more generic bpf_verify_signature() and pass the signature type (suggested by KP) - Move the helper and prototype declaration under #ifdef so that user space can probe for support for the helper (suggested by Daniel) - Describe better the keyring types (suggested by Daniel) - Include linux/bpf.h instead of vmlinux.h to avoid implicit or redeclaration - Make the test selfcontained (suggested by Alexei) Roberto Sassu (2): bpf: Add bpf_verify_signature() helper selftests/bpf: Add test for bpf_verify_signature() helper include/uapi/linux/bpf.h | 17 ++ kernel/bpf/bpf_lsm.c | 46 ++++ tools/include/uapi/linux/bpf.h | 17 ++ tools/testing/selftests/bpf/Makefile | 11 +- tools/testing/selftests/bpf/config | 1 + .../selftests/bpf/prog_tests/verify_sig.c | 200 ++++++++++++++++++ .../selftests/bpf/progs/test_verify_sig.c | 160 ++++++++++++++ .../testing/selftests/bpf/verify_sig_setup.sh | 100 +++++++++ 8 files changed, 549 insertions(+), 3 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/verify_sig.c create mode 100644 tools/testing/selftests/bpf/progs/test_verify_sig.c create mode 100755 tools/testing/selftests/bpf/verify_sig_setup.sh -- 2.25.1

3 years, 1 month

4
9
0 0

[PATCH v2 0/3] bpf: Add bpf_verify_pkcs7_signature() helper

by Roberto Sassu

One of the desirable features in security is the ability to restrict import of data to a given system based on data authenticity. If data import can be restricted, it would be possible to enforce a system-wide policy based on the signing keys the system owner trusts. This feature is widely used in the kernel. For example, if the restriction is enabled, kernel modules can be plugged in only if they are signed with a key whose public part is in the primary or secondary keyring. For eBPF, it can be useful as well. For example, it might be useful to authenticate data an eBPF program makes security decisions on. After a discussion in the eBPF mailing list, it was decided that the stated goal should be accomplished by introducing a new helper: bpf_verify_pkcs7_signature(). It is simply a wrapper of verify_pkcs7_signature(), and does the signature verification with a key in the selected keyring (primary, secondary or platform). Since verify_pkcs7_signature() is doing crypto operations, it must be called by a sleepable program. This restricts the set of functions that can call the associated helper (for example, lsm.s/bpf is suitable, fexit/array_map_update_elem is not). The added test check the ability of an eBPF program to verify module-style appended signatures, as produced by the kernel tool sign-file, currently used to sign kernel modules. The patch set is organized as follows. Patch 1 introduces the new helper. Patch 2 adds two new options to test_progs (the eBPF selftest binary), to specify the path of sign-file and the file containing the kernel private key and certificate. Finally, patch 3 adds the test for the new helper. Roberto Sassu (3): bpf: Add bpf_verify_pkcs7_signature() helper selftests/bpf: Add test_progs opts for sign-file and kernel priv key + cert selftests/bpf: Add test for bpf_verify_pkcs7_signature() helper include/uapi/linux/bpf.h | 8 + kernel/bpf/bpf_lsm.c | 32 ++++ tools/include/uapi/linux/bpf.h | 8 + tools/testing/selftests/bpf/config | 2 + .../bpf/prog_tests/verify_pkcs7_sig.c | 149 ++++++++++++++++++ .../bpf/progs/test_verify_pkcs7_sig.c | 127 +++++++++++++++ tools/testing/selftests/bpf/test_progs.c | 12 ++ tools/testing/selftests/bpf/test_progs.h | 3 + 8 files changed, 341 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/verify_pkcs7_sig.c create mode 100644 tools/testing/selftests/bpf/progs/test_verify_pkcs7_sig.c -- 2.25.1

3 years, 1 month

5
12
0 0

[PATCH] selftests/vm: Add protection_keys tests to run_vmtests

by Kalpana Shetty

Signed-off-by: Kalpana Shetty <kalpana.shetty(a)amd.com> --- tools/testing/selftests/vm/run_vmtests.sh | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/vm/run_vmtests.sh b/tools/testing/selftests/vm/run_vmtests.sh index 41fce8bea929..54a0c28f810c 100755 --- a/tools/testing/selftests/vm/run_vmtests.sh +++ b/tools/testing/selftests/vm/run_vmtests.sh @@ -179,4 +179,11 @@ run_test ./ksm_tests -N -m 1 # KSM test with 2 NUMA nodes and merge_across_nodes = 0 run_test ./ksm_tests -N -m 0 +# protection_keys tests +if [ $VADDR64 -eq 0 ]; then + run_test ./protection_keys_32 +else + run_test ./protection_keys_64 +fi + exit $exitcode -- 2.25.1

3 years, 1 month

4
4
0 0

[PATCH] testing: kselftest_harness: add filtering and enumerating tests

by Jakub Kicinski

As the number of test cases and length of execution grows it's useful to select only a subset of tests. In TLS for instance we have a matrix of variants for different crypto protocols and during development mostly care about testing a handful. This is quicker and makes reading output easier. This patch adds argument parsing to kselftest_harness. It supports a couple of ways to filter things, I could not come up with one way which will cover all cases. The first and simplest switch is -r which takes the name of a test to run (can be specified multiple times). Then there is a handful of group filtering options. f/v/t for filtering by fixture/variant/test. They have both positive (match -> run) and negative versions (match -> skip). If user specifies any positive option we assume the default is not to run the tests. If only negative options are set we assume the tests are supposed to be run by default. Usage: ./tools/testing/selftests/net/tls [-h|-l] [-t|-T|-v|-V|-f|-F|-r name] -h print help -l list all tests -t name include test -T name exclude test -v name include variant -V name exclude variant -f name include fixture -F name exclude fixture -r name run specified test Test filter options can be specified multiple times. The filtering stops at the first match. For example to include all tests from variant 'bla' but not test 'foo' specify '-T foo -v bla'. Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- CC: keescook(a)chromium.org CC: luto(a)amacapital.net CC: wad(a)chromium.org CC: shuah(a)kernel.org CC: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/kselftest_harness.h | 146 +++++++++++++++++++- 1 file changed, 142 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h index 25f4d54067c0..bcbad9fa0039 100644 --- a/tools/testing/selftests/kselftest_harness.h +++ b/tools/testing/selftests/kselftest_harness.h @@ -54,6 +54,7 @@ #define _GNU_SOURCE #endif #include <asm/types.h> +#include <ctype.h> #include <errno.h> #include <stdbool.h> #include <stdint.h> @@ -985,6 +986,132 @@ void __wait_for_test(struct __test_metadata *t) } } +static int test_harness_argv_check(int argc, char **argv) +{ + const char *opts = "FfVvtTr"; + unsigned int i; + + for (i = 0; i < argc; i++) { + if (!strcmp(argv[i], "-l")) { + struct __fixture_variant_metadata *v; + struct __fixture_metadata *f; + struct __test_metadata *t; + + for (f = __fixture_list; f; f = f->next) { + v = f->variant; + t = f->tests; + + if (f == __fixture_list) + fprintf(stderr, "%-20s %-25s %s\n", + "# FIXTURE", "VARIANT", "TEST"); + else + fprintf(stderr, "--------------------------------------------------------------------------------\n"); + + do { + fprintf(stderr, "%-20s %-25s %s\n", + t == f->tests ? f->name : "", + v ? v->name : "", + t ? t->name : ""); + + v = v ? v->next : NULL; + t = t ? t->next : NULL; + } while (v || t); + } + return 1; + } + if (!strcmp(argv[i], "-h")) { +help_and_fail: + argv--; + fprintf(stderr, + "Usage: %s [-h|-l] [-t|-T|-v|-V|-f|-F|-r name]\n" + "\t-h print help\n" + "\t-l list all tests\n" + "\n" + "\t-t name include test\n" + "\t-T name exclude test\n" + "\t-v name include variant\n" + "\t-V name exclude variant\n" + "\t-f name include fixture\n" + "\t-F name exclude fixture\n" + "\t-r name run specified test\n" + "\n" + "Test filter options can be specified " + "multiple times. The filtering stops\n" + "at the first match. For example to " + "include all tests from variant 'bla'\n" + "but not test 'foo' specify '-T foo -v bla'.\n" + "", argv[0]); + return -1; + } + } + + if (argc % 2) { + ksft_print_msg("FATAL: Odd number of arguments\n"); + goto help_and_fail; + } + + for (i = 0; i < argc; i += 2) { + if (strnlen(argv[i], 3) != 2 || argv[i][0] != '-') { + ksft_print_msg("FATAL: invalid option '%s'\n", argv[i]); + goto help_and_fail; + } + + if (!strchr(opts, argv[i][1])) { + ksft_print_msg("FATAL: unknown option '%s'\n", argv[i]); + goto help_and_fail; + } + } + + return 1; +} + +static bool test_enabled(int argc, char **argv, + struct __fixture_metadata *f, + struct __fixture_variant_metadata *v, + struct __test_metadata *t) +{ + unsigned int flen, vlen, tlen = 0; + bool has_positive = false; + unsigned int i; + + for (i = 0; i < argc; i += 2) { + has_positive |= islower(argv[i][1]); + + switch (tolower(argv[i][1])) { + case 't': + if (!strcmp(t->name, argv[i + 1])) + return islower(argv[i][1]); + break; + case 'f': + if (!strcmp(f->name, argv[i + 1])) + return islower(argv[i][1]); + break; + case 'v': + if (!strcmp(v->name, argv[i + 1])) + return islower(argv[i][1]); + break; + case 'r': + if (!tlen) { + flen = strlen(f->name); + vlen = strlen(v->name); + tlen = strlen(t->name); + } + if (strlen(argv[i + 1]) == flen + 1 + vlen + !!vlen + tlen && + !strncmp(f->name, &argv[i + 1][0], flen) && + !strncmp(v->name, &argv[i + 1][flen + 1], vlen) && + !strncmp(t->name, &argv[i + 1][flen + 1 + vlen + !!vlen], tlen)) + return true; + break; + } + } + + /* + * If there are no positive tests then we assume user just wants + * exclusions and everything else is a pass. + */ + return !has_positive; +} + void __run_test(struct __fixture_metadata *f, struct __fixture_variant_metadata *variant, struct __test_metadata *t) @@ -1032,8 +1159,7 @@ void __run_test(struct __fixture_metadata *f, f->name, variant->name[0] ? "." : "", variant->name, t->name); } -static int test_harness_run(int __attribute__((unused)) argc, - char __attribute__((unused)) **argv) +static int test_harness_run(int argc, char **argv) { struct __fixture_variant_metadata no_variant = { .name = "", }; struct __fixture_variant_metadata *v; @@ -1045,11 +1171,21 @@ static int test_harness_run(int __attribute__((unused)) argc, unsigned int count = 0; unsigned int pass_count = 0; + argc--; argv++; /* Skip the name of the binary */ + ret = test_harness_argv_check(argc, argv); + if (ret < 0) + return KSFT_FAIL; + for (f = __fixture_list; f; f = f->next) { for (v = f->variant ?: &no_variant; v; v = v->next) { - case_count++; + unsigned int old_tests = test_count; + for (t = f->tests; t; t = t->next) - test_count++; + if (test_enabled(argc, argv, f, v, t)) + test_count++; + + if (old_tests != test_count) + case_count++; } } @@ -1063,6 +1199,8 @@ static int test_harness_run(int __attribute__((unused)) argc, for (f = __fixture_list; f; f = f->next) { for (v = f->variant ?: &no_variant; v; v = v->next) { for (t = f->tests; t; t = t->next) { + if (!test_enabled(argc, argv, f, v, t)) + continue; count++; t->results = results; __run_test(f, v, t); -- 2.36.1

3 years, 1 month

2
3
0 0

[PATCH v2] selftests/sgx: add test_encl.elf to TEST_GEN_FILES

by Jarkko Sakkinen

TEST_GEN_FILES contains files that are generated during compilation and are required to be included together with the test binaries, e.g. when performing: make -C tools/testing/selftests install INSTALL_PATH=/some/other/path [*] Add test_encl.elf to TEST_GEN_FILES because otherwise the installed test binary will fail to run. [*] https://docs.kernel.org/dev-tools/kselftest.html Cc: stable(a)vger.kernel.org Fixes: 2adcba79e69d ("selftests/x86: Add a selftest for SGX") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v2: Use TEST_GEN_FILES in the "all" target, instead of duplicating the path for test_encl.elf. --- tools/testing/selftests/sgx/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/sgx/Makefile b/tools/testing/selftests/sgx/Makefile index 75af864e07b6..7f60811b5b20 100644 --- a/tools/testing/selftests/sgx/Makefile +++ b/tools/testing/selftests/sgx/Makefile @@ -17,9 +17,10 @@ ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \ -fno-stack-protector -mrdrnd $(INCLUDES) TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx +TEST_GEN_FILES := $(OUTPUT)/test_encl.elf ifeq ($(CAN_BUILD_X86_64), 1) -all: $(TEST_CUSTOM_PROGS) $(OUTPUT)/test_encl.elf +all: $(TEST_CUSTOM_PROGS) $(TEST_GEN_FILES) endif $(OUTPUT)/test_sgx: $(OUTPUT)/main.o \ -- 2.36.1

3 years, 1 month

2
2
0 0

[PATCH v2 0/9] bpf: Per-operation map permissions

by Roberto Sassu

With the bpf_map security hook, an eBPF program is able to restrict access to a map. For example, it might allow only read accesses and deny write accesses. Unfortunately, permissions are not accurately specified by libbpf and bpftool. As a consequence, even if they are requested to perform a read-like operation, such as a map lookup, that operation fails even if the caller has the right to do so. Even worse, the iteration over existing maps stops as soon as a write-protected one is encountered. Maps after the write-protected one are not accessible, even if the user has the right to perform operations on them. At low level, the problem is that open_flags and file_flags, respectively in the bpf_map_get_fd_by_id() and bpf_obj_get(), are set to zero. The kernel interprets this as a request to obtain a file descriptor with full permissions. For some operations, like show or dump, a read file descriptor is enough. Those operations could be still performed even in a write-protected map. Also for searching a map by name, which requires getting the map info, a read file descriptor is enough. If an operation requires more permissions, they could still be requested later, after the search. First, solve both problems by extending libbpf with two new functions, bpf_map_get_fd_by_id_flags() and bpf_obj_get_flags(), which unlike their counterparts bpf_map_get_fd_by_id() and bpf_obj_get(), have the additional parameter flags to specify the needed permissions for an operation. Then, propagate the flags in bpftool from the functions implementing the subcommands down to the functions calling bpf_map_get_fd_by_id() and bpf_obj_get(), and replace the latter functions with their new variant. Initially, set the flags to zero, so that the current behavior does not change. The only exception is for map search by name, where a read-only permission is requested, regardless of the operation, to get the map info. In this case, request a new file descriptor if a write-like operation needs to be performed after the search. Finally, identify other read-like operations in bpftool and for those replace the zero value for flags with BPF_F_RDONLY. The patch set is organized as follows. Patches 1-2 introduce the two new variants of bpf_map_get_fd_by_id() and bpf_obj_get() in libbpf, named respectively bpf_map_get_fd_by_id_flags() and bpf_obj_get_flags(). Patches 3-7 propagate the flags in bpftool from the functions implementing the subcommands to the two new libbpf functions, and always set flags to BPF_F_RDONLY for the map search operation. Patch 8 adjusts permissions depending on the map operation performed. Patch 9 ensures that read-only accesses to a write-protected map succeed and write accesses still fail. Also ensure that map search is always successful even if there are write-protected maps. Changelog v1: - Define per-operation permissions rather than retrying access with read-only permission (suggested by Daniel) https://lore.kernel.org/bpf/20220530084514.10170-1-roberto.sassu@huawei.com/ Roberto Sassu (9): libbpf: Introduce bpf_map_get_fd_by_id_flags() libbpf: Introduce bpf_obj_get_flags() bpftool: Add flags parameter to open_obj_pinned_any() and open_obj_pinned() bpftool: Add flags parameter to *_parse_fd() functions bpftool: Add flags parameter to map_parse_fds() bpftool: Add flags parameter to map_parse_fd_and_info() bpftool: Add flags parameter in struct_ops functions bpftool: Adjust map permissions selftests/bpf: Add map access tests tools/bpf/bpftool/btf.c | 11 +- tools/bpf/bpftool/cgroup.c | 4 +- tools/bpf/bpftool/common.c | 52 ++-- tools/bpf/bpftool/iter.c | 2 +- tools/bpf/bpftool/link.c | 9 +- tools/bpf/bpftool/main.h | 17 +- tools/bpf/bpftool/map.c | 24 +- tools/bpf/bpftool/map_perf_ring.c | 3 +- tools/bpf/bpftool/net.c | 2 +- tools/bpf/bpftool/prog.c | 12 +- tools/bpf/bpftool/struct_ops.c | 39 ++- tools/lib/bpf/bpf.c | 16 +- tools/lib/bpf/bpf.h | 2 + tools/lib/bpf/libbpf.map | 2 + .../bpf/prog_tests/test_map_check_access.c | 264 ++++++++++++++++++ .../selftests/bpf/progs/map_check_access.c | 65 +++++ 16 files changed, 452 insertions(+), 72 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/test_map_check_access.c create mode 100644 tools/testing/selftests/bpf/progs/map_check_access.c -- 2.25.1

3 years, 1 month

2
14
0 0

[PATCH v5 0/4] fat: add support for the renameat2 RENAME_EXCHANGE flag

by Javier Martinez Canillas

Hello, The series adds support for the renameat2 system call RENAME_EXCHANGE flag (which allows to atomically replace two paths) to the vfat filesystem code. There are many use cases for this, but we are particularly interested in making possible for vfat filesystems to be part of OSTree [0] deployments. Currently OSTree relies on symbolic links to make the deployment updates an atomic transactional operation. But RENAME_EXCHANGE could be used [1] to achieve a similar level of robustness when using a vfat filesystem. Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE support, patch #2 moves some code blocks in vfat_rename() to a set of helper functions, that can be reused by tvfat_rename_exchange() that's added by patch #3 and finally patch #4 adds some kselftests to test it. This is a v5 that addresses issues pointed out in v4: https://lore.kernel.org/lkml/18d9e587-b4f7-6ee7-185a-af0e667e0ec5@redhat.co… [0]: https://github.com/ostreedev/ostree [1]: https://github.com/ostreedev/ostree/issues/1649 Changes in v5: - Only update nlink for different parent dirs and file types (OGAWA Hirofumi). Changes in v4: - Add new patch from OGAWA Hirofumi to use the helpers in vfat_rename(). - Rebase the patch on top of OGAWA Hirofumi proposed changes. - Drop iversion increment for old and new file inodes (OGAWA Hirofumi). - Add Muhammad Usama Anjum Acked-by tag. Changes in v3: - Add a .gitignore for the rename_exchange binary (Muhammad Usama Anjum). - Include $(KHDR_INCLUDES) instead of hardcoding a relative path in Makefile (Muhammad Usama Anjum). Changes in v2: - Only update the new_dir inode version and timestamps if != old_dir (Alex Larsson). - Add some helper functions to avoid duplicating code (OGAWA Hirofumi). - Use braces for multi-lines blocks even if are one statement (OGAWA Hirofumi). - Mention in commit message that the operation is as transactional as possible but within the vfat limitations of not having a journal (Colin Walters). - Call sync to flush the page cache before checking the file contents (Alex Larsson). - Drop RFC prefix since the patches already got some review. Javier Martinez Canillas (3): fat: add a vfat_rename2() and make existing .rename callback a helper fat: add renameat2 RENAME_EXCHANGE flag support selftests/filesystems: add a vfat RENAME_EXCHANGE test OGAWA Hirofumi (1): fat: factor out reusable code in vfat_rename() as helper functions MAINTAINERS | 1 + fs/fat/namei_vfat.c | 232 +++++++++++++++--- tools/testing/selftests/Makefile | 1 + .../selftests/filesystems/fat/.gitignore | 2 + .../selftests/filesystems/fat/Makefile | 7 + .../testing/selftests/filesystems/fat/config | 2 + .../filesystems/fat/rename_exchange.c | 37 +++ .../filesystems/fat/run_fat_tests.sh | 82 +++++++ 8 files changed, 325 insertions(+), 39 deletions(-) create mode 100644 tools/testing/selftests/filesystems/fat/.gitignore create mode 100644 tools/testing/selftests/filesystems/fat/Makefile create mode 100644 tools/testing/selftests/filesystems/fat/config create mode 100644 tools/testing/selftests/filesystems/fat/rename_exchange.c create mode 100755 tools/testing/selftests/filesystems/fat/run_fat_tests.sh -- 2.36.1

3 years, 1 month

1
1
0 0

[PATCH v4 0/4] fat: add support for the renameat2 RENAME_EXCHANGE flag

by Javier Martinez Canillas

Hello, The series adds support for the renameat2 system call RENAME_EXCHANGE flag (which allows to atomically replace two paths) to the vfat filesystem code. There are many use cases for this, but we are particularly interested in making possible for vfat filesystems to be part of OSTree [0] deployments. Currently OSTree relies on symbolic links to make the deployment updates an atomic transactional operation. But RENAME_EXCHANGE could be used [1] to achieve a similar level of robustness when using a vfat filesystem. Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE support, patch #2 moves some code blocks in vfat_rename() to a set of helper functions, that can be reused by tvfat_rename_exchange() that's added by patch #3 and finally patch #4 adds some kselftests to test it. This is a v4 that addresses issues pointed out in the third version posted: https://www.spinics.net/lists/kernel/msg4373694.html [0]: https://github.com/ostreedev/ostree [1]: https://github.com/ostreedev/ostree/issues/1649 Changes in v4: - Add new patch from OGAWA Hirofumi to use the helpers in vfat_rename(). - Rebase the patch on top of OGAWA Hirofumi proposed changes. - Drop iversion increment for old and new file inodes (OGAWA Hirofumi). - Add Muhammad Usama Anjum Acked-by tag. Changes in v3: - Add a .gitignore for the rename_exchange binary (Muhammad Usama Anjum). - Include $(KHDR_INCLUDES) instead of hardcoding a relative path in Makefile (Muhammad Usama Anjum). Changes in v2: - Only update the new_dir inode version and timestamps if != old_dir (Alex Larsson). - Add some helper functions to avoid duplicating code (OGAWA Hirofumi). - Use braces for multi-lines blocks even if are one statement (OGAWA Hirofumi). - Mention in commit message that the operation is as transactional as possible but within the vfat limitations of not having a journal (Colin Walters). - Call sync to flush the page cache before checking the file contents (Alex Larsson). - Drop RFC prefix since the patches already got some review. Javier Martinez Canillas (3): fat: add a vfat_rename2() and make existing .rename callback a helper fat: add renameat2 RENAME_EXCHANGE flag support selftests/filesystems: add a vfat RENAME_EXCHANGE test OGAWA Hirofumi (1): fat: factor out reusable code in vfat_rename() as helper functions MAINTAINERS | 1 + fs/fat/namei_vfat.c | 222 +++++++++++++++--- tools/testing/selftests/Makefile | 1 + .../selftests/filesystems/fat/.gitignore | 2 + .../selftests/filesystems/fat/Makefile | 7 + .../testing/selftests/filesystems/fat/config | 2 + .../filesystems/fat/rename_exchange.c | 37 +++ .../filesystems/fat/run_fat_tests.sh | 82 +++++++ 8 files changed, 315 insertions(+), 39 deletions(-) create mode 100644 tools/testing/selftests/filesystems/fat/.gitignore create mode 100644 tools/testing/selftests/filesystems/fat/Makefile create mode 100644 tools/testing/selftests/filesystems/fat/config create mode 100644 tools/testing/selftests/filesystems/fat/rename_exchange.c create mode 100755 tools/testing/selftests/filesystems/fat/run_fat_tests.sh -- 2.36.1

3 years, 1 month

2
4
0 0

Napływ Klientów ze strony

by Wiktor Nurek

Dzień dobry, chciałbym poinformować Państwa o możliwości pozyskania nowych zleceń ze strony www. Widzimy zainteresowanie potencjalnych Klientów Państwa firmą, dlatego chętnie pomożemy Państwu dotrzeć z ofertą do większego grona odbiorców poprzez efektywne metody pozycjonowania strony w Google. Czy mógłbym liczyć na kontakt zwrotny? Pozdrawiam serdecznie, Wiktor Nurek

3 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror