Initially I just wanted to port the selftests to the latest GPIO uAPI,
but on finding that, due to dependency issues, the selftests are not built
for the buildroot environments that I do most of my GPIO testing in, I
decided to take a closer look.
The first patch is essentially a rewrite of the exising test suite.
It uses a simplified abstraction of the uAPI interfaces to allow a common
test suite to test the gpio-mockup using either of the uAPI interfaces.
The simplified cdev interface is implemented in gpio-mockup.sh, with the
actual driving of the uAPI implemented in gpio-mockup-cdev.c.
The simplified sysfs interface replaces gpio-mockup-sysfs.sh and is
loaded over the cdev implementation when selected.
The new tests should also be simpler to extend to cover new mockup
interfaces, such as the one Bart has been working on.
I have dropped support for testing modules other than gpio-mockup from
the command line options, as the tests are very gpio-mockup specific so
I didn't see any calling for it.
I have also tried to emphasise in the test output that the tests are
covering the gpio-mockup itself. They do perform some implicit testing
of gpiolib and the uAPI interfaces, and so can be useful as smoke tests
for those, but their primary focus is the gpio-mockup.
Patches 2 through 5 do some cleaning up that is now possible with the
new implementation, including enabling building in buildroot environments.
Patch 4 doesn't strictly clean up all the old gpio references that it
could - the gpio was the only Level 1 test, so the Level 1 tests could
potentially be removed, but I was unsure if there may be other
implications to removing a whole test level, or that it may be useful
as a placeholder in case other static LDLIBS tests are added in
the future??
Patch 6 finally gets around to porting the tests to the latest GPIO uAPI.
And Patch 7 updates the config to set the CONFIG_GPIO_CDEV option that
was added in v5.10.
Cheers,
Kent.
Changes v1 -> v2 (all in patch 1 and gpio-mockup.sh unless stated
otherwise):
- reorder includes in gpio-mockup-cdev.c
- a multitude of improvements to gpio-mockup.sh and gpio-mockup-sysfs.sh
based on Andy's review comments
- improved cleanup to ensure all child processes are killed on exit
- added race condition prevention or mitigation including the wait in
release_line, the retries in assert_mock, the assert_mock in set_mock,
and the sleep in set_line
Kent Gibson (7):
selftests: gpio: rework and simplify test implementation
selftests: gpio: remove obsolete gpio-mockup-chardev.c
selftests: remove obsolete build restriction for gpio
selftests: remove obsolete gpio references from kselftest_deps.sh
tools: gpio: remove uAPI v1 code no longer used by selftests
selftests: gpio: port to GPIO uAPI v2
selftests: gpio: add CONFIG_GPIO_CDEV to config
tools/gpio/gpio-utils.c | 89 ----
tools/gpio/gpio-utils.h | 6 -
tools/testing/selftests/Makefile | 9 -
tools/testing/selftests/gpio/Makefile | 26 +-
tools/testing/selftests/gpio/config | 1 +
.../testing/selftests/gpio/gpio-mockup-cdev.c | 198 +++++++
.../selftests/gpio/gpio-mockup-chardev.c | 323 ------------
.../selftests/gpio/gpio-mockup-sysfs.sh | 168 ++----
tools/testing/selftests/gpio/gpio-mockup.sh | 497 ++++++++++++------
tools/testing/selftests/kselftest_deps.sh | 4 +-
10 files changed, 603 insertions(+), 718 deletions(-)
create mode 100644 tools/testing/selftests/gpio/gpio-mockup-cdev.c
delete mode 100644 tools/testing/selftests/gpio/gpio-mockup-chardev.c
--
2.30.0
This series contains a few cleanups that didn't make it into previous
series, including some cosmetic changes and small bug fixes. The series
also lays the groundwork for a memslot modification test which stresses
the memslot update and page fault code paths in an attempt to expose races.
Tested: dirty_log_perf_test, memslot_modification_stress_test, and
demand_paging_test were run, with all the patches in this series
applied, on an Intel Skylake machine.
echo Y > /sys/module/kvm/parameters/tdp_mmu; \
./memslot_modification_stress_test -i 1000 -v 64 -b 1G; \
./memslot_modification_stress_test -i 1000 -v 64 -b 64M -o; \
./dirty_log_perf_test -v 64 -b 1G; \
./dirty_log_perf_test -v 64 -b 64M -o; \
./demand_paging_test -v 64 -b 1G; \
./demand_paging_test -v 64 -b 64M -o; \
echo N > /sys/module/kvm/parameters/tdp_mmu; \
./memslot_modification_stress_test -i 1000 -v 64 -b 1G; \
./memslot_modification_stress_test -i 1000 -v 64 -b 64M -o; \
./dirty_log_perf_test -v 64 -b 1G; \
./dirty_log_perf_test -v 64 -b 64M -o; \
./demand_paging_test -v 64 -b 1G; \
./demand_paging_test -v 64 -b 64M -o
The tests behaved as expected, and fixed the problem of the
population stage being skipped in dirty_log_perf_test. This can be
seen in the output, with the population stage taking about the time
dirty pass 1 took and dirty pass 1 falling closer to the times for
the other passes.
Note that when running these tests, the -o option causes the test to take
much longer as the work each vCPU must do increases proportional to the
number of vCPUs.
You can view this series in Gerrit at:
https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/7…
Ben Gardon (6):
KVM: selftests: Rename timespec_diff_now to timespec_elapsed
KVM: selftests: Avoid flooding debug log while populating memory
KVM: selftests: Convert iterations to int in dirty_log_perf_test
KVM: selftests: Fix population stage in dirty_log_perf_test
KVM: selftests: Add option to overlap vCPU memory access
KVM: selftests: Add memslot modification stress test
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/demand_paging_test.c | 40 +++-
.../selftests/kvm/dirty_log_perf_test.c | 72 +++---
.../selftests/kvm/include/perf_test_util.h | 4 +-
.../testing/selftests/kvm/include/test_util.h | 2 +-
.../selftests/kvm/lib/perf_test_util.c | 25 ++-
tools/testing/selftests/kvm/lib/test_util.c | 2 +-
.../kvm/memslot_modification_stress_test.c | 211 ++++++++++++++++++
9 files changed, 307 insertions(+), 51 deletions(-)
create mode 100644 tools/testing/selftests/kvm/memslot_modification_stress_test.c
--
2.30.0.284.gd98b1dd5eaa7-goog
Changelog
---------
v4
- Address page migration comments. New patch:
mm/gup: limit number of gup migration failures, honor failures
Implements the limiting number of retries for migration failures, and
also check for isolation failures.
Added a test case into gup_test to verify that pages never long-term
pinned in a movable zone, and also added tests to fault both in kernel
and in userland.
v3
- Merged with linux-next, which contains clean-up patch from Jason,
therefore this series is reduced by two patches which did the same
thing.
v2
- Addressed all review comments
- Added Reviewed-by's.
- Renamed PF_MEMALLOC_NOMOVABLE to PF_MEMALLOC_PIN
- Added is_pinnable_page() to check if page can be longterm pinned
- Fixed gup fast path by checking is_in_pinnable_zone()
- rename cma_page_list to movable_page_list
- add a admin-guide note about handling pinned pages in ZONE_MOVABLE,
updated caveat about pinned pages from linux/mmzone.h
- Move current_gfp_context() to fast-path
---------
When page is pinned it cannot be moved and its physical address stays
the same until pages is unpinned.
This is useful functionality to allows userland to implementation DMA
access. For example, it is used by vfio in vfio_pin_pages().
However, this functionality breaks memory hotplug/hotremove assumptions
that pages in ZONE_MOVABLE can always be migrated.
This patch series fixes this issue by forcing new allocations during
page pinning to omit ZONE_MOVABLE, and also to migrate any existing
pages from ZONE_MOVABLE during pinning.
It uses the same scheme logic that is currently used by CMA, and extends
the functionality for all allocations.
For more information read the discussion [1] about this problem.
[1] https://lore.kernel.org/lkml/CA+CK2bBffHBxjmb9jmSKacm0fJMinyt3Nhk8Nx6iudcQS…
Previous versions:
v1
https://lore.kernel.org/lkml/20201202052330.474592-1-pasha.tatashin@soleen.…
v2
https://lore.kernel.org/lkml/20201210004335.64634-1-pasha.tatashin@soleen.c…
v3
https://lore.kernel.org/lkml/20201211202140.396852-1-pasha.tatashin@soleen.…
Pavel Tatashin (10):
mm/gup: don't pin migrated cma pages in movable zone
mm cma: rename PF_MEMALLOC_NOCMA to PF_MEMALLOC_PIN
mm: apply per-task gfp constraints in fast path
mm: honor PF_MEMALLOC_PIN for all movable pages
mm/gup: migrate pinned pages out of movable zone
memory-hotplug.rst: add a note about ZONE_MOVABLE and page pinning
mm/gup: change index type to long as it counts pages
mm/gup: limit number of gup migration failures, honor failures
selftests/vm: test flag is broken
selftests/vm: test faulting in kernel, and verify pinnable pages
.../admin-guide/mm/memory-hotplug.rst | 9 +
include/linux/migrate.h | 1 +
include/linux/mm.h | 11 +
include/linux/mmzone.h | 11 +-
include/linux/sched.h | 2 +-
include/linux/sched/mm.h | 27 +--
include/trace/events/migrate.h | 3 +-
mm/gup.c | 217 ++++++++++--------
mm/gup_test.c | 15 +-
mm/gup_test.h | 1 +
mm/hugetlb.c | 4 +-
mm/page_alloc.c | 33 ++-
mm/vmscan.c | 10 +-
tools/testing/selftests/vm/gup_test.c | 26 ++-
14 files changed, 221 insertions(+), 149 deletions(-)
--
2.25.1
On Mon, Jan 11, 2021 at 9:34 AM Alan Maguire <alan.maguire(a)oracle.com> wrote:
>
> libbpf already supports a "dumper" API for dumping type information,
> but there is currently no support for dumping typed _data_ via libbpf.
> However this functionality does exist in the kernel, in part to
> facilitate the bpf_snprintf_btf() helper which dumps a string
> representation of the pointer passed in utilizing the BTF type id
> of the data pointed to. For example, the pair of a pointer to
> a "struct sk_buff" and the BTF type id of "struct sk_buff" can be
> used.
>
> Here the kernel code is generalized into btf_show_common.c. For the
> most part, code is identical for userspace and kernel, beyond a few API
> differences and missing functions. The only significant differences are
>
> - the "safe copy" logic used by the kernel to ensure we do not induce a
> crash during BPF operation; and
> - the BTF seq file support that is kernel-only.
>
> The mechanics are to maintain identical btf_show_common.c files in
> kernel/bpf and tools/lib/bpf , and a common header btf_common.h in
> include/linux/ and tools/lib/bpf/. This file duplication seems to
> be the common practice with duplication between kernel and tools/
> so it's the approach taken here.
>
> The common code approach could likely be explored further, but here
> the minimum common code required to support BTF show functionality is
> used.
>
I don't think this approach will work. libbpf and kernel have
considerably different restrictions and styles, I don't think it's
appropriate to take kernel code and try to fit it into libbpf almost
as is, with a bunch of #defines. It would be much cleaner, simpler,
and more maintainable to just re-implement core logic for libbpf, IMO.
> Currently the only "show" function for userspace is to write the
> representation of the typed data to a string via
>
> LIBBPF_API int
> btf__snprintf(struct btf *btf, char *buf, int len, __u32 id, void *obj,
> __u64 flags);
>
> ...but other approaches could be pursued including printf()-based
> show, or even a callback mechanism could be supported to allow
> user-defined show functions.
>
It's strange that you saw btf_dump APIs, and yet decided to go with
this API instead. snprintf() is not a natural "method" of struct btf.
Using char buffer as an output is overly restrictive and inconvenient.
It's appropriate for kernel and BPF program due to their restrictions,
but there is no need to cripple libbpf APIs for that. I think it
should follow btf_dump APIs with custom callback so that it's easy to
just printf() everything, but also user can create whatever elaborate
mechanism they need and that fits their use case.
Code reuse is not the ultimate goal, it should facilitate
maintainability, not harm it. There are times where sharing code
introduces unnecessary coupling and maintainability issues. And I
think this one is a very obvious case of that.
See below a few comments as well. But overall it's really hard to
review such a humongous patch, of course. So I so far just skimmed
through it.
> Here's an example usage, storing a string representation of
> struct sk_buff *skb in buf:
>
> struct btf *btf = libbpf_find_kernel_btf();
> char buf[8192];
> __s32 skb_id;
>
> skb_id = btf__find_by_name_kind(btf, "sk_buff", BTF_KIND_STRUCT);
> if (skb_id < 0)
> fprintf(stderr, "no skbuff, err %d\n", skb_id);
> else
> btf__snprintf(btf, buf, sizeof(buf), skb_id, skb, 0);
>
> Suggested-by: Alexei Starovoitov <ast(a)kernel.org>
> Signed-off-by: Alan Maguire <alan.maguire(a)oracle.com>
> ---
> include/linux/btf.h | 121 +---
> include/linux/btf_common.h | 286 +++++++++
> kernel/bpf/Makefile | 2 +-
> kernel/bpf/arraymap.c | 1 +
> kernel/bpf/bpf_struct_ops.c | 1 +
> kernel/bpf/btf.c | 1215 +-------------------------------------
> kernel/bpf/btf_show_common.c | 1218 +++++++++++++++++++++++++++++++++++++++
> kernel/bpf/core.c | 1 +
> kernel/bpf/hashtab.c | 1 +
> kernel/bpf/local_storage.c | 1 +
> kernel/bpf/verifier.c | 1 +
> kernel/trace/bpf_trace.c | 1 +
> tools/lib/bpf/Build | 2 +-
> tools/lib/bpf/btf.h | 7 +
> tools/lib/bpf/btf_common.h | 286 +++++++++
> tools/lib/bpf/btf_show_common.c | 1218 +++++++++++++++++++++++++++++++++++++++
> tools/lib/bpf/libbpf.map | 1 +
> 17 files changed, 3044 insertions(+), 1319 deletions(-)
> create mode 100644 include/linux/btf_common.h
> create mode 100644 kernel/bpf/btf_show_common.c
> create mode 100644 tools/lib/bpf/btf_common.h
> create mode 100644 tools/lib/bpf/btf_show_common.c
>
[...]
> +/* For kernel u64 is long long unsigned int... */
> +#define FMT64 "ll"
> +
> +#else
> +/* ...while for userspace it is long unsigned int. These definitions avoid
> + * format specifier warnings.
> + */
that's not true, it depends on the architecture
> +#define FMT64 "l"
> +
> +/* libbpf names differ slightly to in-kernel function names. */
> +#define btf_type_by_id btf__type_by_id
> +#define btf_name_by_offset btf__name_by_offset
> +#define btf_str_by_offset btf__str_by_offset
> +#define btf_resolve_size btf__resolve_size
ugh... good luck navigating the code in libbpf....
> +
> +#endif /* __KERNEL__ */
> +/*
> + * Options to control show behaviour.
> + * - BTF_SHOW_COMPACT: no formatting around type information
> + * - BTF_SHOW_NONAME: no struct/union member names/types
> + * - BTF_SHOW_PTR_RAW: show raw (unobfuscated) pointer values;
> + * equivalent to %px.
> + * - BTF_SHOW_ZERO: show zero-valued struct/union members; they
> + * are not displayed by default
> + * - BTF_SHOW_UNSAFE: skip use of bpf_probe_read() to safely read
> + * data before displaying it.
> + */
> +#define BTF_SHOW_COMPACT BTF_F_COMPACT
> +#define BTF_SHOW_NONAME BTF_F_NONAME
> +#define BTF_SHOW_PTR_RAW BTF_F_PTR_RAW
> +#define BTF_SHOW_ZERO BTF_F_ZERO
> +#define BTF_SHOW_UNSAFE (1ULL << 4)
this (or some subset of them) should be done as opts struct's bool
fields for libbpf
> +
> +/*
> + * Copy len bytes of string representation of obj of BTF type_id into buf.
> + *
> + * @btf: struct btf object
> + * @type_id: type id of type obj points to
> + * @obj: pointer to typed data
> + * @buf: buffer to write to
> + * @len: maximum length to write to buf
> + * @flags: show options (see above)
> + *
> + * Return: length that would have been/was copied as per snprintf, or
> + * negative error.
> + */
> +int btf_type_snprintf_show(const struct btf *btf, u32 type_id, void *obj,
> + char *buf, int len, u64 flags);
> +
> +#define for_each_member(i, struct_type, member) \
> + for (i = 0, member = btf_type_member(struct_type); \
> + i < btf_type_vlen(struct_type); \
> + i++, member++)
> +
> +#define for_each_vsi(i, datasec_type, member) \
> + for (i = 0, member = btf_type_var_secinfo(datasec_type); \
> + i < btf_type_vlen(datasec_type); \
> + i++, member++)
> +
> +static inline bool btf_type_is_ptr(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_PTR;
> +}
> +
> +static inline bool btf_type_is_int(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_INT;
> +}
> +
> +static inline bool btf_type_is_small_int(const struct btf_type *t)
> +{
> + return btf_type_is_int(t) && t->size <= sizeof(u64);
> +}
> +
> +static inline bool btf_type_is_enum(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_ENUM;
> +}
> +
> +static inline bool btf_type_is_typedef(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_TYPEDEF;
> +}
> +
> +static inline bool btf_type_is_func(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_FUNC;
> +}
> +
> +static inline bool btf_type_is_func_proto(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_FUNC_PROTO;
> +}
> +
> +static inline bool btf_type_is_var(const struct btf_type *t)
> +{
> + return BTF_INFO_KIND(t->info) == BTF_KIND_VAR;
> +}
> +
> +/* union is only a special case of struct:
> + * all its offsetof(member) == 0
> + */
> +static inline bool btf_type_is_struct(const struct btf_type *t)
> +{
> + u8 kind = BTF_INFO_KIND(t->info);
> +
> + return kind == BTF_KIND_STRUCT || kind == BTF_KIND_UNION;
> +}
> +
> +static inline bool btf_type_is_modifier(const struct btf_type *t)
> +{
> + /* Some of them is not strictly a C modifier
> + * but they are grouped into the same bucket
> + * for BTF concern:
> + * A type (t) that refers to another
> + * type through t->type AND its size cannot
> + * be determined without following the t->type.
> + *
> + * ptr does not fall into this bucket
> + * because its size is always sizeof(void *).
> + */
> + switch (BTF_INFO_KIND(t->info)) {
> + case BTF_KIND_TYPEDEF:
> + case BTF_KIND_VOLATILE:
> + case BTF_KIND_CONST:
> + case BTF_KIND_RESTRICT:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static inline
> +const struct btf_type *btf_type_skip_modifiers(const struct btf *btf,
> + u32 id, u32 *res_id)
> +{
> + const struct btf_type *t = btf_type_by_id(btf, id);
> +
> + while (btf_type_is_modifier(t)) {
> + id = t->type;
> + t = btf_type_by_id(btf, t->type);
> + }
> +
> + if (res_id)
> + *res_id = id;
> +
> + return t;
> +}
> +
> +static inline u32 btf_type_int(const struct btf_type *t)
> +{
> + return *(u32 *)(t + 1);
> +}
> +
> +static inline const struct btf_array *btf_type_array(const struct btf_type *t)
> +{
> + return (const struct btf_array *)(t + 1);
> +}
> +
> +static inline const struct btf_enum *btf_type_enum(const struct btf_type *t)
> +{
> + return (const struct btf_enum *)(t + 1);
> +}
> +
> +static inline const struct btf_var *btf_type_var(const struct btf_type *t)
> +{
> + return (const struct btf_var *)(t + 1);
> +}
> +
> +static inline u16 btf_type_vlen(const struct btf_type *t)
> +{
> + return BTF_INFO_VLEN(t->info);
> +}
> +
> +static inline u16 btf_func_linkage(const struct btf_type *t)
> +{
> + return BTF_INFO_VLEN(t->info);
> +}
> +
> +/* size can be used */
> +static inline bool btf_type_has_size(const struct btf_type *t)
> +{
> + switch (BTF_INFO_KIND(t->info)) {
> + case BTF_KIND_INT:
> + case BTF_KIND_STRUCT:
> + case BTF_KIND_UNION:
> + case BTF_KIND_ENUM:
> + case BTF_KIND_DATASEC:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static inline const struct btf_member *btf_type_member(const struct btf_type *t)
> +{
> + return (const struct btf_member *)(t + 1);
> +}
> +
> +static inline const struct btf_var_secinfo *btf_type_var_secinfo(
> + const struct btf_type *t)
> +{
> + return (const struct btf_var_secinfo *)(t + 1);
> +}
> +
> +static inline const char *__btf_name_by_offset(const struct btf *btf,
> + u32 offset)
> +{
> + const char *name;
> +
> + if (!offset)
> + return "(anon)";
> +
> + name = btf_str_by_offset(btf, offset);
> + return name ?: "(invalid-name-offset)";
> +}
> +
(almost?) all of the above helpers are already defined in libbpf's
btf.h, no need to add all this duplication
> +/* functions shared between btf.c and btf_show_common.c */
> +void btf_type_ops_show(const struct btf *btf, const struct btf_type *t,
> + __u32 type_id, void *obj, u8 bits_offset,
> + struct btf_show *show);
[...]
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index 1c0fd2d..35bd9dc 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -346,6 +346,7 @@ LIBBPF_0.3.0 {
> btf__parse_split;
> btf__new_empty_split;
> btf__new_split;
> + btf__snprintf;
It's LIBBPF_0.4.0 already, I or someone else should send a patch
adding a new section in .map file.
> ring_buffer__epoll_fd;
> xsk_setup_xdp_prog;
> xsk_socket__update_xskmap;
> --
> 1.8.3.1
>
Commit fadb08e7c750 ("kunit: Support for Parameterized Testing")
introduced support but lacks documentation for how to use it.
This patch builds on commit 1f0e943df68a ("Documentation: kunit: provide
guidance for testing many inputs") to show a minimal example of the new
feature.
Signed-off-by: Daniel Latypov <dlatypov(a)google.com>
---
Documentation/dev-tools/kunit/usage.rst | 57 +++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index d9fdc14f0677..650f99590df5 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -522,6 +522,63 @@ There's more boilerplate involved, but it can:
* E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256``
field and reuse ``cases``.
+* be converted to a "parameterized test", see below.
+
+Parameterized Testing
+~~~~~~~~~~~~~~~~~~~~~
+
+The table-driven testing pattern is common enough that KUnit has special
+support for it.
+
+Reusing the same ``cases`` array from above, we can write the test as a
+"parameterized test" with the following.
+
+.. code-block:: c
+
+ // This is copy-pasted from above.
+ struct sha1_test_case {
+ const char *str;
+ const char *sha1;
+ };
+ struct sha1_test_case cases[] = {
+ {
+ .str = "hello world",
+ .sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
+ },
+ {
+ .str = "hello world!",
+ .sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
+ },
+ };
+
+ // Need a helper function to generate a name for each test case.
+ static void case_to_desc(const struct sha1_test_case *t, char *desc)
+ {
+ strcpy(desc, t->str);
+ }
+ // Creates `sha1_gen_params()` to iterate over `cases`.
+ KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc);
+
+ // Looks no different from a normal test.
+ static void sha1_test(struct kunit *test)
+ {
+ // This function can just contain the body of the for-loop.
+ // The former `cases[i]` is accessible under test->param_value.
+ char out[40];
+ struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
+
+ sha1sum(test_param->str, out);
+ KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1,
+ "sha1sum(%s)", test_param->str);
+ }
+
+ // Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the
+ // function declared by KUNIT_ARRAY_PARAM.
+ static struct kunit_case sha1_test_cases[] = {
+ KUNIT_CASE_PARAM(sha1_test, sha1_gen_params),
+ {}
+ };
+
.. _kunit-on-non-uml:
KUnit on non-UML architectures
base-commit: 5f6b99d0287de2c2d0b5e7abcb0092d553ad804a
--
2.29.2.684.gfbc64c5ab5-goog
Hi Linus,
Please pull the following Kselftest fixes update for Linux 5.11-rc4
This Kselftest fixes update for Linux 5.11-rc4 consists of one single
fix to skip BPF selftests by default. BPF selftests have a hard
dependency on cutting edge versions of tools in the BPF ecosystem
including LLVM.
Skipping BPF allows by default will make it easier for users interested
in running kselftest as a whole. Users can include BPF in Kselftest
build by via SKIP_TARGETS variable.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-fixes-5.11-rc4
for you to fetch changes up to 7a6eb7c34a78498742b5f82543b7a68c1c443329:
selftests: Skip BPF seftests by default (2021-01-04 09:27:20 -0700)
----------------------------------------------------------------
linux-kselftest-fixes-5.11-rc4
This Kselftest fixes update for Linux 5.11-rc4 consists of one single
fix to skip BPF selftests by default. BPF selftests have a hard
dependency on cutting edge versions of tools in the BPF ecosystem
including LLVM.
Skipping BPF allows by default will make it easier for users interested
in running kselftest as a whole. Users can include BPF in Kselftest
build by via SKIP_TARGETS variable.
----------------------------------------------------------------
Mark Brown (1):
selftests: Skip BPF seftests by default
tools/testing/selftests/Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
----------------------------------------------------------------
Add support for pointer to mem register spilling, to allow the verifier
to track pointers to valid memory addresses. Such pointers are returned
for example by a successful call of the bpf_ringbuf_reserve helper.
The patch was partially contributed by CyberArk Software, Inc.
Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
Suggested-by: Yonghong Song <yhs(a)fb.com>
Signed-off-by: Gilad Reti <gilad.reti(a)gmail.com>
---
kernel/bpf/verifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 17270b8404f1..36af69fac591 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2217,6 +2217,8 @@ static bool is_spillable_regtype(enum bpf_reg_type type)
case PTR_TO_RDWR_BUF:
case PTR_TO_RDWR_BUF_OR_NULL:
case PTR_TO_PERCPU_BTF_ID:
+ case PTR_TO_MEM:
+ case PTR_TO_MEM_OR_NULL:
return true;
default:
return false;
--
2.27.0
A few fixes for cross-building the sefltests out of tree. This will
enable wider automated testing on various Arm hardware.
Changes since v1 [1]:
* Use wildcard in patch 5
* Move the MAKE_DIRS declaration in patch 1
[1] https://lore.kernel.org/bpf/20210112135959.649075-1-jean-philippe@linaro.or…
Jean-Philippe Brucker (5):
selftests/bpf: Enable cross-building
selftests/bpf: Fix out-of-tree build
selftests/bpf: Move generated test files to $(TEST_GEN_FILES)
selftests/bpf: Fix installation of urandom_read
selftests/bpf: Install btf_dump test cases
tools/testing/selftests/bpf/Makefile | 58 ++++++++++++++++++++--------
1 file changed, 41 insertions(+), 17 deletions(-)
--
2.30.0
Following the build fixes for bpftool [1], here are a few fixes for
cross-building the sefltests out of tree. This will enable wider
automated testing on various Arm hardware.
[1] https://lore.kernel.org/bpf/20201110164310.2600671-1-jean-philippe@linaro.o…
Jean-Philippe Brucker (5):
selftests/bpf: Enable cross-building
selftests/bpf: Fix out-of-tree build
selftests/bpf: Move generated test files to $(TEST_GEN_FILES)
selftests/bpf: Fix installation of urandom_read
selftests/bpf: Install btf_dump test cases
tools/testing/selftests/bpf/Makefile | 61 +++++++++++++++++++++-------
1 file changed, 46 insertions(+), 15 deletions(-)
--
2.30.0
The BPF Type Format (BTF) can be used in conjunction with the helper
bpf_snprintf_btf() to display kernel data with type information.
This series generalizes that support and shares it with libbpf so
that libbpf can display typed data. BTF display functionality is
factored out of kernel/bpf/btf.c into kernel/bpf/btf_show_common.c,
and that file is duplicated in tools/lib/bpf. Similarly, common
definitions and inline functions needed for this support are
extracted into include/linux/btf_common.h and this header is again
duplicated in tools/lib/bpf.
Patch 1 carries out the refactoring, for which no kernel changes
are intended, and introduces btf__snprintf() a libbpf function
that supports dumping a string representation of typed data using
the struct btf * and id associated with that type.
Patch 2 tests btf__snprintf() with built-in and kernel types to
ensure data is of expected format. The test closely mirrors
the BPF program associated with the snprintf_btf.c; in this case
however the string representations are verified in userspace rather
than in BPF program context.
Alan Maguire (2):
bpf: share BTF "show" implementation between kernel and libbpf
selftests/bpf: test libbpf-based type display
include/linux/btf.h | 121 +-
include/linux/btf_common.h | 286 +++++
kernel/bpf/Makefile | 2 +-
kernel/bpf/arraymap.c | 1 +
kernel/bpf/bpf_struct_ops.c | 1 +
kernel/bpf/btf.c | 1215 +------------------
kernel/bpf/btf_show_common.c | 1218 ++++++++++++++++++++
kernel/bpf/core.c | 1 +
kernel/bpf/hashtab.c | 1 +
kernel/bpf/local_storage.c | 1 +
kernel/bpf/verifier.c | 1 +
kernel/trace/bpf_trace.c | 1 +
tools/lib/bpf/Build | 2 +-
tools/lib/bpf/btf.h | 7 +
tools/lib/bpf/btf_common.h | 286 +++++
tools/lib/bpf/btf_show_common.c | 1218 ++++++++++++++++++++
tools/lib/bpf/libbpf.map | 1 +
.../selftests/bpf/prog_tests/snprintf_btf_user.c | 192 +++
18 files changed, 3236 insertions(+), 1319 deletions(-)
create mode 100644 include/linux/btf_common.h
create mode 100644 kernel/bpf/btf_show_common.c
create mode 100644 tools/lib/bpf/btf_common.h
create mode 100644 tools/lib/bpf/btf_show_common.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/snprintf_btf_user.c
--
1.8.3.1
If a signed number field starts with a '-' the field width must be > 1,
or unlimited, to allow at least one digit after the '-'.
This patch adds a check for this. If a signed field starts with '-'
and field_width == 1 the scanf will quit.
It is ok for a signed number field to have a field width of 1 if it
starts with a digit. In that case the single digit can be converted.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
---
lib/vsprintf.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 14c9a6af1b23..8954ff94a53c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -3433,8 +3433,12 @@ int vsscanf(const char *buf, const char *fmt, va_list args)
str = skip_spaces(str);
digit = *str;
- if (is_sign && digit == '-')
+ if (is_sign && digit == '-') {
+ if (field_width == 1)
+ break;
+
digit = *(str + 1);
+ }
if (!digit
|| (base == 16 && !isxdigit(digit))
--
2.20.1
Hi Linus,
Please pull the following fixes update for Linux 5.11-rc3.
This fixes update for 5.11-rc3 consists of two minor fixes to vDSO test
changes in 5.11-rc1 update.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-next-5.11-rc3
for you to fetch changes up to df00d02989024d193a6efd1a85513a5658c6a10f:
selftests/vDSO: fix -Wformat warning in vdso_test_correctness
(2021-01-04 09:25:45 -0700)
----------------------------------------------------------------
linux-kselftest-next-5.11-rc3
This fixes update for 5.11-rc3 consists of two minor fixes to vDSO test
changes in 5.11-rc1 update.
----------------------------------------------------------------
Tobias Klauser (2):
selftests/vDSO: add additional binaries to .gitignore
selftests/vDSO: fix -Wformat warning in vdso_test_correctness
tools/testing/selftests/vDSO/.gitignore | 3 +++
tools/testing/selftests/vDSO/vdso_test_correctness.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
----------------------------------------------------------------
Hi Linus,
Please pull the following KUnit fixes update for Linux 5.11-rc3.
This kunit update for Linux 5.11-rc3 consists one fix to force the use
of the 'tty' console for UML. Given that kunit tool requires the console
output, explicitly stating the dependency makes sense than relying on
it being the default.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-kunit-fixes-5.11-rc3
for you to fetch changes up to 65a4e5299739abe0888cda0938d21f8ea3b5c606:
kunit: tool: Force the use of the 'tty' console for UML (2021-01-04
09:18:38 -0700)
----------------------------------------------------------------
linux-kselftest-kunit-fixes-5.11-rc3
This kunit update for Linux 5.11-rc3 consists one fix to force the use
of the 'tty' console for UML. Given that kunit tool requires the console
output, explicitly stating the dependency makes sense than relying on
it being the default.
----------------------------------------------------------------
David Gow (1):
kunit: tool: Force the use of the 'tty' console for UML
tools/testing/kunit/kunit_kernel.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------
kunit_tool relies on the UML console outputting printk() output to the
tty in order to get results. Since the default console driver could
change, pass 'console=tty' to the kernel.
This is triggered by a change[1] to use ttynull as a fallback console
driver which -- by chance or by design -- seems to have changed the
default console output on UML, breaking kunit_tool. While this may be
fixed, we should be less fragile to such changes in the default.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
Signed-off-by: David Gow <davidgow(a)google.com>
Fixes: 757055ae8ded ("init/console: Use ttynull as a fallback when there is no console")
---
tools/testing/kunit/kunit_kernel.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
index 57c1724b7e5d..698358c9c0d6 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -198,7 +198,7 @@ class LinuxSourceTree(object):
return self.validate_config(build_dir)
def run_kernel(self, args=[], build_dir='', timeout=None):
- args.extend(['mem=1G'])
+ args.extend(['mem=1G', 'console=tty'])
self._ops.linux_bin(args, timeout, build_dir)
outfile = get_outfile_path(build_dir)
subprocess.call(['stty', 'sane'])
--
2.29.2.729.g45daf8777d-goog
Hi!
For last few weeks KUnit stopped working. Any insight?
P.S. I guess no need to tell that my kernel on which I run tests has not been
changed as well as command line for wrapper:
tools/testing/kunit/kunit.py run --build_dir ~/$OUT_DIR
--
With Best Regards,
Andy Shevchenko
Initially I just wanted to port the selftests to the latest GPIO uAPI,
but on finding that, due to dependency issues, the selftests are not built
for the buildroot environments that I do most of my GPIO testing in, I
decided to take a closer look.
The first patch is essentially a rewrite of the exising test suite.
It uses a simplified abstraction of the uAPI interfaces to allow a common
test suite to test the gpio-mockup using either of the uAPI interfaces.
The simplified cdev interface is implemented in gpio-mockup.sh, with the
actual driving of the uAPI implemented in gpio-mockup-cdev.c.
The simplified sysfs interface replaces gpio-mockup-sysfs.sh and is
loaded over the cdev implementation when selected.
The new tests should also be simpler to extend to cover new mockup
interfaces, such as the one Bart has been working on.
I have dropped support for testing modules other than gpio-mockup from
the command line options, as the tests are very gpio-mockup specific so
I didn't see any calling for it.
I have also tried to emphasise in the test output that the tests are
covering the gpio-mockup itself. They do perform some implicit testing
of gpiolib and the uAPI interfaces, and so can be useful as smoke tests
for those, but their primary focus is the gpio-mockup.
Patches 2 through 5 do some cleaning up that is now possible with the
new implementation, including enabling building in buildroot environments.
Patch 4 doesn't strictly clean up all the old gpio references that it
could - the gpio was the only Level 1 test, so the Level 1 tests could
potentially be removed, but I was unsure if there may be other
implications to removing a whole test level, or that it may be useful
as a placeholder in case other static LDLIBS tests are added in
the future??
Patch 6 finally gets around to porting the tests to the latest GPIO uAPI.
And Patch 7 updates the config to set the CONFIG_GPIO_CDEV option that
was added in v5.10.
Cheers,
Kent.
Kent Gibson (7):
selftests: gpio: rework and simplify test implementation
selftests: gpio: remove obsolete gpio-mockup-chardev.c
selftests: remove obsolete build restriction for gpio
selftests: remove obsolete gpio references from kselftest_deps.sh
tools: gpio: remove uAPI v1 code no longer used by selftests
selftests: gpio: port to GPIO uAPI v2
selftests: gpio: add CONFIG_GPIO_CDEV to config
tools/gpio/gpio-utils.c | 89 ----
tools/gpio/gpio-utils.h | 6 -
tools/testing/selftests/Makefile | 9 -
tools/testing/selftests/gpio/Makefile | 26 +-
tools/testing/selftests/gpio/config | 1 +
.../testing/selftests/gpio/gpio-mockup-cdev.c | 198 ++++++++
.../selftests/gpio/gpio-mockup-chardev.c | 323 ------------
.../selftests/gpio/gpio-mockup-sysfs.sh | 168 ++-----
tools/testing/selftests/gpio/gpio-mockup.sh | 469 ++++++++++++------
tools/testing/selftests/kselftest_deps.sh | 4 +-
10 files changed, 573 insertions(+), 720 deletions(-)
create mode 100644 tools/testing/selftests/gpio/gpio-mockup-cdev.c
delete mode 100644 tools/testing/selftests/gpio/gpio-mockup-chardev.c
--
2.30.0
When running this xfrm_policy.sh test script, even with some cases
marked as FAIL, the overall test result will still be PASS:
$ sudo ./xfrm_policy.sh
PASS: policy before exception matches
FAIL: expected ping to .254 to fail (exceptions)
PASS: direct policy matches (exceptions)
PASS: policy matches (exceptions)
FAIL: expected ping to .254 to fail (exceptions and block policies)
PASS: direct policy matches (exceptions and block policies)
PASS: policy matches (exceptions and block policies)
FAIL: expected ping to .254 to fail (exceptions and block policies after hresh changes)
PASS: direct policy matches (exceptions and block policies after hresh changes)
PASS: policy matches (exceptions and block policies after hresh changes)
FAIL: expected ping to .254 to fail (exceptions and block policies after hthresh change in ns3)
PASS: direct policy matches (exceptions and block policies after hthresh change in ns3)
PASS: policy matches (exceptions and block policies after hthresh change in ns3)
FAIL: expected ping to .254 to fail (exceptions and block policies after htresh change to normal)
PASS: direct policy matches (exceptions and block policies after htresh change to normal)
PASS: policy matches (exceptions and block policies after htresh change to normal)
PASS: policies with repeated htresh change
$ echo $?
0
This is because the $lret in check_xfrm() is not a local variable.
Therefore when a test failed in check_exceptions(), the non-zero $lret
will later get reset to 0 when the next test calls check_xfrm().
With this fix, the final return value will be 1. Make it easier for
testers to spot this failure.
Fixes: 39aa6928d462d0 ("xfrm: policy: fix netlink/pf_key policy lookups")
Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com>
---
tools/testing/selftests/net/xfrm_policy.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/xfrm_policy.sh b/tools/testing/selftests/net/xfrm_policy.sh
index 7a1bf94..5922941 100755
--- a/tools/testing/selftests/net/xfrm_policy.sh
+++ b/tools/testing/selftests/net/xfrm_policy.sh
@@ -202,7 +202,7 @@ check_xfrm() {
# 1: iptables -m policy rule count != 0
rval=$1
ip=$2
- lret=0
+ local lret=0
ip netns exec ns1 ping -q -c 1 10.0.2.$ip > /dev/null
--
2.7.4
On Sat, Jan 02, 2021 at 03:52:32PM +0200, Andy Shevchenko wrote:
> On Saturday, January 2, 2021, Kent Gibson <warthog618(a)gmail.com> wrote:
>
> > The GPIO mockup selftests are overly complicated with separate
> > implementations of the tests for sysfs and cdev uAPI, and with the cdev
> > implementation being dependent on tools/gpio and libmount.
> >
> > Rework the test implementation to provide a common test suite with a
> > simplified pluggable uAPI interface. The cdev implementation utilises
> > the GPIO uAPI directly to remove the dependence on tools/gpio.
> > The simplified uAPI interface removes the need for any file system mount
> > checks in C, and so removes the dependence on libmount.
> >
> > The rework also fixes the sysfs test implementation which has been broken
> > since the device created in the multiple gpiochip case was split into
> > separate devices.
> >
> >
>
> I briefly looked at code in shell below... there are places to improve
> (useless use of: cat, test, negation, etc).
>
My shell is clearly pretty poor, so I would really appreciate a pointer
to an example of each, and I'll then hunt down the rest.
Thanks,
Kent.
From: Ira Weiny <ira.weiny(a)intel.com>
Changes from V2 [4]
Rebased on tip-tree/core/entry
From Thomas Gleixner
Address bisectability
Drop Patch:
x86/entry: Move nmi entry/exit into common code
From Greg KH
Remove WARN_ON's
From Dan Williams
Add __must_check to pks_key_alloc()
New patch: x86/pks: Add PKS defines and config options
Split from Enable patch to build on through the series
Fix compile errors
Changes from V1
Rebase to TIP master; resolve conflicts and test
Clean up some kernel docs updates missed in V1
Add irqentry_state_t kernel doc for PKRS field
Removed redundant irq_state->pkrs
This is only needed when we add the global state and somehow
ended up in this patch series. That will come back when we add
the global functionality in.
From Thomas Gleixner
Update commit messages
Add kernel doc for struct irqentry_state_t
From Dave Hansen add flags to pks_key_alloc()
Changes from RFC V3[3]
Rebase to TIP master
Update test error output
Standardize on 'irq_state' for state variables
From Dave Hansen
Update commit messages
Add/clean up comments
Add X86_FEATURE_PKS to disabled-features.h and remove some
explicit CONFIG checks
Move saved_pkrs member of thread_struct
Remove superfluous preempt_disable()
s/irq_save_pks/irq_save_set_pks/
Ensure PKRS is not seen in faults if not configured or not
supported
s/pks_mknoaccess/pks_mk_noaccess/
s/pks_mkread/pks_mk_readonly/
s/pks_mkrdwr/pks_mk_readwrite/
Change pks_key_alloc return to -EOPNOTSUPP when not supported
From Peter Zijlstra
Clean up Attribution
Remove superfluous preempt_disable()
Add union to differentiate exit_rcu/lockdep use in
irqentry_state_t
From Thomas Gleixner
Add preliminary clean up patch and adjust series as needed
Introduce a new page protection mechanism for supervisor pages, Protection Key
Supervisor (PKS).
2 use cases for PKS are being developed, trusted keys and PMEM. Trusted keys
is a newer use case which is still being explored. PMEM was submitted as part
of the RFC (v2) series[1]. However, since then it was found that some callers
of kmap() require a global implementation of PKS. Specifically some users of
kmap() expect mappings to be available to all kernel threads. While global use
of PKS is rare it needs to be included for correctness. Unfortunately the
kmap() updates required a large patch series to make the needed changes at the
various kmap() call sites so that patch set has been split out. Because the
global PKS feature is only required for that use case it will be deferred to
that set as well.[2] This patch set is being submitted as a precursor to both
of the use cases.
For an overview of the entire PKS ecosystem, a git tree including this series
and 2 proposed use cases can be found here:
https://lore.kernel.org/lkml/20201009195033.3208459-1-ira.weiny@intel.com/https://lore.kernel.org/lkml/20201009201410.3209180-1-ira.weiny@intel.com/
PKS enables protections on 'domains' of supervisor pages to limit supervisor
mode access to those pages beyond the normal paging protections. PKS works in
a similar fashion to user space pkeys, PKU. As with PKU, supervisor pkeys are
checked in addition to normal paging protections and Access or Writes can be
disabled via a MSR update without TLB flushes when permissions change. Also
like PKU, a page mapping is assigned to a domain by setting pkey bits in the
page table entry for that mapping.
Access is controlled through a PKRS register which is updated via WRMSR/RDMSR.
XSAVE is not supported for the PKRS MSR. Therefore the implementation
saves/restores the MSR across context switches and during exceptions. Nested
exceptions are supported by each exception getting a new PKS state.
For consistent behavior with current paging protections, pkey 0 is reserved and
configured to allow full access via the pkey mechanism, thus preserving the
default paging protections on mappings with the default pkey value of 0.
Other keys, (1-15) are allocated by an allocator which prepares us for key
contention from day one. Kernel users should be prepared for the allocator to
fail either because of key exhaustion or due to PKS not being supported on the
arch and/or CPU instance.
The following are key attributes of PKS.
1) Fast switching of permissions
1a) Prevents access without page table manipulations
1b) No TLB flushes required
2) Works on a per thread basis
PKS is available with 4 and 5 level paging. Like PKRU it consumes 4 bits from
the PTE to store the pkey within the entry.
[1] https://lore.kernel.org/lkml/20200717072056.73134-1-ira.weiny@intel.com/
[2] https://lore.kernel.org/lkml/20201009195033.3208459-2-ira.weiny@intel.com/
[3] https://lore.kernel.org/lkml/20201009194258.3207172-1-ira.weiny@intel.com/
[4] https://lore.kernel.org/lkml/20201102205320.1458656-1-ira.weiny@intel.com/
Fenghua Yu (2):
x86/pks: Add PKS kernel API
x86/pks: Enable Protection Keys Supervisor (PKS)
Ira Weiny (8):
x86/pkeys: Create pkeys_common.h
x86/fpu: Refactor arch_set_user_pkey_access() for PKS support
x86/pks: Add PKS defines and Kconfig options
x86/pks: Preserve the PKRS MSR on context switch
x86/entry: Pass irqentry_state_t by reference
x86/entry: Preserve PKRS MSR across exceptions
x86/fault: Report the PKRS state on fault
x86/pks: Add PKS test code
Documentation/core-api/protection-keys.rst | 103 ++-
arch/x86/Kconfig | 1 +
arch/x86/entry/common.c | 46 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/disabled-features.h | 8 +-
arch/x86/include/asm/idtentry.h | 25 +-
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/asm/pgtable.h | 13 +-
arch/x86/include/asm/pgtable_types.h | 12 +
arch/x86/include/asm/pkeys.h | 15 +
arch/x86/include/asm/pkeys_common.h | 40 ++
arch/x86/include/asm/processor.h | 18 +-
arch/x86/include/uapi/asm/processor-flags.h | 2 +
arch/x86/kernel/cpu/common.c | 15 +
arch/x86/kernel/cpu/mce/core.c | 4 +-
arch/x86/kernel/fpu/xstate.c | 22 +-
arch/x86/kernel/kvm.c | 6 +-
arch/x86/kernel/nmi.c | 4 +-
arch/x86/kernel/process.c | 26 +
arch/x86/kernel/traps.c | 21 +-
arch/x86/mm/fault.c | 87 ++-
arch/x86/mm/pkeys.c | 196 +++++-
include/linux/entry-common.h | 31 +-
include/linux/pgtable.h | 4 +
include/linux/pkeys.h | 24 +
kernel/entry/common.c | 44 +-
lib/Kconfig.debug | 12 +
lib/Makefile | 3 +
lib/pks/Makefile | 3 +
lib/pks/pks_test.c | 692 ++++++++++++++++++++
mm/Kconfig | 2 +
tools/testing/selftests/x86/Makefile | 3 +-
tools/testing/selftests/x86/test_pks.c | 66 ++
33 files changed, 1410 insertions(+), 140 deletions(-)
create mode 100644 arch/x86/include/asm/pkeys_common.h
create mode 100644 lib/pks/Makefile
create mode 100644 lib/pks/pks_test.c
create mode 100644 tools/testing/selftests/x86/test_pks.c
--
2.28.0.rc0.12.gb6a658bd00c9
This patch set contains dm-user, a device mapper target that proxies incoming
BIOs to userspace via a misc device. Essentially it's FUSE, but for block
devices. There's more information in the documentation patch and as a handful
of commends, so I'm just going to avoid duplicating that here. I don't really
think there's any fundamental functionality that dm-user enables, as one could
use something along the lines of nbd/iscsi, but dm-user does result in
extremely simple userspace daemons -- so simple that when I tried to write a
helper userspace library for dm-user I just ended up with nothing.
I talked about this a bit at Plumbers and was hoping to send patches a bit
earlier on in the process, but got tied up with a few things. As a result this
is actually quite far along: it's at the point where we're starting to run this
on real devices as part of an updated Android OTA update flow, where we're
using this to provide an Android-specific compressed backing store for
dm-snap-persistent. The bulk of that project is scattered throughout the
various Android trees, so there are kselftests and a (somewhat bare for now)
Documentation entry with the intent of making this a self-contained
contribution. There's a lot to the Android userspace daemon, but it doesn't
interact with dm-user in a very complex manner.
This is still in a somewhat early stage, but it's at the point where things
largely function. I'm certainly not ready to commit to the user ABI
implemented here and there are a bunch of FIXMEs scattered throughout the code,
but I do think that it's far along enough to begin a more concrete discussion
of where folks would like to go with something like this. While I'd intending
on sorting that stuff out, I'd like to at least get a feel for whether this is
a path worth pursuing before spending a bunch more time on it.
I haven't done much in the way of performance analysis for dm-user. Earlier on
I did some simple throughput tests and found that dm-user/ext4 was faster than
half the speed of tmpfs, which is way out of the realm of being an issue for
our use case (decompressing blocks out of a phone's storage). The design of
dm-user does preclude an extremely high performance implementation, where I
assume one would want an explicit ring buffer and zero copy, but I feel like
users who want that degree of performance are probably better served writing a
proper kernel driver. I wouldn't be opposed to pushing on performance (ideally
without a major design change), but for now I feel like time is better spent
fortifying the user ABI and fixing the various issues with the implementation.
The patches follow as usual, but in case it's easier I've published a tree as
well:
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/dm-user.git -b dm-user-v1
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit 716572b0003ef67a4889bd7d85baf5099c5a0248 ]
Setting GS to 1, 2, or 3 causes a nonsensical part of the IRET microcode
to change GS back to zero on a return from kernel mode to user mode. The
result is that these tests fail randomly depending on when interrupts
happen. Detect when this happens and let the test pass.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Link: https://lkml.kernel.org/r/7567fd44a1d60a9424f25b19a998f12149993b0d.16043465…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/x86/fsgsbase.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/fsgsbase.c b/tools/testing/selftests/x86/fsgsbase.c
index f249e042b3b51..026cd644360f6 100644
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -318,8 +318,8 @@ static void set_gs_and_switch_to(unsigned long local,
local = read_base(GS);
/*
- * Signal delivery seems to mess up weird selectors. Put it
- * back.
+ * Signal delivery is quite likely to change a selector
+ * of 1, 2, or 3 back to 0 due to IRET being defective.
*/
asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
} else {
@@ -337,6 +337,14 @@ static void set_gs_and_switch_to(unsigned long local,
if (base == local && sel_pre_sched == sel_post_sched) {
printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
sel_pre_sched, local);
+ } else if (base == local && sel_pre_sched >= 1 && sel_pre_sched <= 3 &&
+ sel_post_sched == 0) {
+ /*
+ * IRET is misdesigned and will squash selectors 1, 2, or 3
+ * to zero. Don't fail the test just because this happened.
+ */
+ printf("[OK]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx because IRET is defective\n",
+ sel_pre_sched, local, sel_post_sched, base);
} else {
nerrs++;
printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
--
2.27.0
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit 716572b0003ef67a4889bd7d85baf5099c5a0248 ]
Setting GS to 1, 2, or 3 causes a nonsensical part of the IRET microcode
to change GS back to zero on a return from kernel mode to user mode. The
result is that these tests fail randomly depending on when interrupts
happen. Detect when this happens and let the test pass.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Link: https://lkml.kernel.org/r/7567fd44a1d60a9424f25b19a998f12149993b0d.16043465…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/x86/fsgsbase.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/fsgsbase.c b/tools/testing/selftests/x86/fsgsbase.c
index f249e042b3b51..026cd644360f6 100644
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -318,8 +318,8 @@ static void set_gs_and_switch_to(unsigned long local,
local = read_base(GS);
/*
- * Signal delivery seems to mess up weird selectors. Put it
- * back.
+ * Signal delivery is quite likely to change a selector
+ * of 1, 2, or 3 back to 0 due to IRET being defective.
*/
asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
} else {
@@ -337,6 +337,14 @@ static void set_gs_and_switch_to(unsigned long local,
if (base == local && sel_pre_sched == sel_post_sched) {
printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
sel_pre_sched, local);
+ } else if (base == local && sel_pre_sched >= 1 && sel_pre_sched <= 3 &&
+ sel_post_sched == 0) {
+ /*
+ * IRET is misdesigned and will squash selectors 1, 2, or 3
+ * to zero. Don't fail the test just because this happened.
+ */
+ printf("[OK]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx because IRET is defective\n",
+ sel_pre_sched, local, sel_post_sched, base);
} else {
nerrs++;
printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
--
2.27.0
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit 716572b0003ef67a4889bd7d85baf5099c5a0248 ]
Setting GS to 1, 2, or 3 causes a nonsensical part of the IRET microcode
to change GS back to zero on a return from kernel mode to user mode. The
result is that these tests fail randomly depending on when interrupts
happen. Detect when this happens and let the test pass.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Link: https://lkml.kernel.org/r/7567fd44a1d60a9424f25b19a998f12149993b0d.16043465…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/x86/fsgsbase.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/fsgsbase.c b/tools/testing/selftests/x86/fsgsbase.c
index f249e042b3b51..026cd644360f6 100644
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -318,8 +318,8 @@ static void set_gs_and_switch_to(unsigned long local,
local = read_base(GS);
/*
- * Signal delivery seems to mess up weird selectors. Put it
- * back.
+ * Signal delivery is quite likely to change a selector
+ * of 1, 2, or 3 back to 0 due to IRET being defective.
*/
asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
} else {
@@ -337,6 +337,14 @@ static void set_gs_and_switch_to(unsigned long local,
if (base == local && sel_pre_sched == sel_post_sched) {
printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
sel_pre_sched, local);
+ } else if (base == local && sel_pre_sched >= 1 && sel_pre_sched <= 3 &&
+ sel_post_sched == 0) {
+ /*
+ * IRET is misdesigned and will squash selectors 1, 2, or 3
+ * to zero. Don't fail the test just because this happened.
+ */
+ printf("[OK]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx because IRET is defective\n",
+ sel_pre_sched, local, sel_post_sched, base);
} else {
nerrs++;
printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
--
2.27.0
From: Andy Lutomirski <luto(a)kernel.org>
[ Upstream commit 716572b0003ef67a4889bd7d85baf5099c5a0248 ]
Setting GS to 1, 2, or 3 causes a nonsensical part of the IRET microcode
to change GS back to zero on a return from kernel mode to user mode. The
result is that these tests fail randomly depending on when interrupts
happen. Detect when this happens and let the test pass.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Link: https://lkml.kernel.org/r/7567fd44a1d60a9424f25b19a998f12149993b0d.16043465…
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/x86/fsgsbase.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/fsgsbase.c b/tools/testing/selftests/x86/fsgsbase.c
index 757bdb218a661..f2916838a7eb5 100644
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -391,8 +391,8 @@ static void set_gs_and_switch_to(unsigned long local,
local = read_base(GS);
/*
- * Signal delivery seems to mess up weird selectors. Put it
- * back.
+ * Signal delivery is quite likely to change a selector
+ * of 1, 2, or 3 back to 0 due to IRET being defective.
*/
asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
} else {
@@ -410,6 +410,14 @@ static void set_gs_and_switch_to(unsigned long local,
if (base == local && sel_pre_sched == sel_post_sched) {
printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
sel_pre_sched, local);
+ } else if (base == local && sel_pre_sched >= 1 && sel_pre_sched <= 3 &&
+ sel_post_sched == 0) {
+ /*
+ * IRET is misdesigned and will squash selectors 1, 2, or 3
+ * to zero. Don't fail the test just because this happened.
+ */
+ printf("[OK]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx because IRET is defective\n",
+ sel_pre_sched, local, sel_post_sched, base);
} else {
nerrs++;
printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
--
2.27.0
From: Jean-Philippe Brucker <jean-philippe(a)linaro.org>
[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
The test fails because of a recent fix to the verifier, even though this
program is valid. In details what happens is:
7: (61) r1 = *(u32 *)(r0 +0)
Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds
of the 64-bit value are [0, U32_MAX]...
8: (65) if r1 s> 0xffffffff goto pc+1
... therefore this is always true (the operand is sign-extended).
10: (b4) w2 = 11
11: (6d) if r2 s> r1 goto pc+1
When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still
[S32_MIN, 10].
13: (64) w1 <<= 2
Because this is a 32-bit operation, the verifier propagates the new
32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11
is lost.
14: (0f) r0 += r1
15: (7a) *(u64 *)(r0 +0) = 4
Then the verifier considers r0 unbounded here, rejecting the test. To
make the test work, change insn 8 to check the sign of the 32-bit value.
Signed-off-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org>
Acked-by: John Fastabend <john.fastabend(a)gmail.com>
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/bpf/verifier/array_access.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/verifier/array_access.c b/tools/testing/selftests/bpf/verifier/array_access.c
index f3c33e128709b..a80d806ead15f 100644
--- a/tools/testing/selftests/bpf/verifier/array_access.c
+++ b/tools/testing/selftests/bpf/verifier/array_access.c
@@ -68,7 +68,7 @@
BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9),
BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0),
- BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1),
+ BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1),
BPF_MOV32_IMM(BPF_REG_1, 0),
BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES),
BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1),
--
2.27.0
On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck <linux(a)roeck-us.net> wrote:
>
> This patch results in:
>
> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of 'request_irq' declared with attribute 'warn_unused_result'
>
> when building sh:defconfig. Checking for calls to request_irq()
> suggests that there will be other similar errors in various builds.
> Reverting the patch fixes the problem.
Which ones? From a quick grep and some filtering I could only find one
file with wrong usage apart from this one:
drivers/net/ethernet/lantiq_etop.c:
request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
drivers/net/ethernet/lantiq_etop.c:
request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
Of course, this does not cover other functions, but it means there
aren't many issues and/or people building the code if nobody complains
within a few weeks. So I think we can fix them as they come.
Cheers,
Miguel