The benchmark command handling (-b) in resctrl selftests is overly
complicated code. This series turns the benchmark command immutable to
preserve it for all selftests and improves benchmark command related
error handling.
This series also ends up removing the strcpy() calls which were pointed
out earlier.
v2:
- Added argument length check into patch 1/7
- Updated also -b line in help message.
- Document -b argument related "algorithm"
- Use asprintf() to convert defined constant int to string
- Improved changelog texts
- Added \n to ksft_exit_fail_msg() call messages.
- Print DEFAULT_SPAN with %u instead of %zu to avoid need to cast it
Ilpo Järvinen (7):
selftests/resctrl: Ensure the benchmark commands fits to its array
selftests/resctrl: Correct benchmark command help
selftests/resctrl: Remove bw_report and bm_type from main()
selftests/resctrl: Simplify span lifetime
selftests/resctrl: Make benchmark command const and build it with
pointers
selftests/resctrl: Remove ben_count variable
selftests/resctrl: Cleanup benchmark argument parsing
tools/testing/selftests/resctrl/cache.c | 5 +-
tools/testing/selftests/resctrl/cat_test.c | 13 +-
tools/testing/selftests/resctrl/cmt_test.c | 34 +++--
tools/testing/selftests/resctrl/mba_test.c | 4 +-
tools/testing/selftests/resctrl/mbm_test.c | 7 +-
tools/testing/selftests/resctrl/resctrl.h | 19 ++-
.../testing/selftests/resctrl/resctrl_tests.c | 122 ++++++++++--------
tools/testing/selftests/resctrl/resctrl_val.c | 10 +-
8 files changed, 125 insertions(+), 89 deletions(-)
--
2.30.2
From: Rong Tao <rongtao(a)cestc.cn>
Static ksyms often have problems because the number of symbols exceeds the
MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in
commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves
the problem somewhat, but it's not the perfect way.
This commit uses dynamic memory allocation, which completely solves the
problem caused by the limitation of the number of kallsyms.
Acked-by: Stanislav Fomichev <sdf(a)google.com>
Signed-off-by: Rong Tao <rongtao(a)cestc.cn>
---
v5: Release the allocated memory once the load_kallsyms_refresh() upon error
given it's dynamically allocated.
v4: https://lore.kernel.org/lkml/tencent_59C74613113F0C728524B2A82FE5540A5E09@q…
Make sure most cases we don't need the realloc() path to begin with,
and check strdup() return value.
v3: https://lore.kernel.org/lkml/tencent_50B4B2622FE7546A5FF9464310650C008509@q…
Do not use structs and judge ksyms__add_symbol function return value.
v2: https://lore.kernel.org/lkml/tencent_B655EE5E5D463110D70CD2846AB3262EED09@q…
Do the usual len/capacity scheme here to amortize the cost of realloc, and
don't free symbols.
v1: https://lore.kernel.org/lkml/tencent_AB461510B10CD484E0B2F62E3754165F2909@q…
---
tools/testing/selftests/bpf/trace_helpers.c | 62 +++++++++++++++++----
1 file changed, 52 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c
index f83d9f65c65b..0053ba22f0cb 100644
--- a/tools/testing/selftests/bpf/trace_helpers.c
+++ b/tools/testing/selftests/bpf/trace_helpers.c
@@ -18,10 +18,47 @@
#define TRACEFS_PIPE "/sys/kernel/tracing/trace_pipe"
#define DEBUGFS_PIPE "/sys/kernel/debug/tracing/trace_pipe"
-#define MAX_SYMS 400000
-static struct ksym syms[MAX_SYMS];
+static struct ksym *syms;
+static int sym_cap;
static int sym_cnt;
+static int ksyms__add_symbol(const char *name, unsigned long addr)
+{
+ void *tmp;
+ unsigned int new_cap;
+
+ if (sym_cnt + 1 > sym_cap) {
+ new_cap = sym_cap * 4 / 3;
+ tmp = realloc(syms, sizeof(struct ksym) * new_cap);
+ if (!tmp)
+ return -ENOMEM;
+ syms = tmp;
+ sym_cap = new_cap;
+ }
+
+ tmp = strdup(name);
+ if (!tmp)
+ return -ENOMEM;
+ syms[sym_cnt].addr = addr;
+ syms[sym_cnt].name = tmp;
+
+ sym_cnt++;
+
+ return 0;
+}
+
+static void ksyms__free(void)
+{
+ unsigned int i;
+
+ if (!syms)
+ return;
+
+ for (i = 0; i < sym_cnt; i++)
+ free(syms[i].name);
+ free(syms);
+}
+
static int ksym_cmp(const void *p1, const void *p2)
{
return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr;
@@ -33,9 +70,14 @@ int load_kallsyms_refresh(void)
char func[256], buf[256];
char symbol;
void *addr;
- int i = 0;
+ int ret;
+ /* Make sure most cases we don't need the realloc() path to begin with */
+ sym_cap = 400000;
sym_cnt = 0;
+ syms = malloc(sizeof(struct ksym) * sym_cap);
+ if (!syms)
+ return -ENOMEM;
f = fopen("/proc/kallsyms", "r");
if (!f)
@@ -46,17 +88,17 @@ int load_kallsyms_refresh(void)
break;
if (!addr)
continue;
- if (i >= MAX_SYMS)
- return -EFBIG;
-
- syms[i].addr = (long) addr;
- syms[i].name = strdup(func);
- i++;
+ ret = ksyms__add_symbol(func, (unsigned long)addr);
+ if (ret)
+ goto error;
}
fclose(f);
- sym_cnt = i;
qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp);
return 0;
+
+error:
+ ksyms__free();
+ return ret;
}
int load_kallsyms(void)
--
2.39.3
This is to add Intel VT-d nested translation based on IOMMUFD nesting
infrastructure. As the iommufd nesting infrastructure series[1], iommu
core supports new ops to report iommu hardware information, allocate
domains with user data and invalidate stage-1 IOTLB when there is mapping
changed in stage-1 page table. The data required in the three paths are
vendor-specific, so
1) IOMMU_HWPT_TYPE_VTD_S1 is defined for the Intel VT-d stage-1 page
table, it will be used in the stage-1 domain allocation and IOTLB
syncing path. struct iommu_hwpt_vtd_s1 is defined to pass user_data
for the Intel VT-d stage-1 domain allocation.
struct iommu_hwpt_vtd_s1_invalidate is defined to pass the data for
the Intel VT-d stage-1 IOTLB invalidation.
2) IOMMU_HW_INFO_TYPE_INTEL_VTD and struct iommu_hw_info_vtd are defined
to report iommu hardware information for Intel VT-d.
With above IOMMUFD extensions, the intel iommu driver implements the three
paths to support nested translation.
The first Intel platform supporting nested translation is Sapphire
Rapids which, unfortunately, has a hardware errata [2] requiring special
treatment. This errata happens when a stage-1 page table page (either
level) is located in a stage-2 read-only region. In that case the IOMMU
hardware may ignore the stage-2 RO permission and still set the A/D bit
in stage-1 page table entries during page table walking.
A flag IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17 is introduced to report
this errata to userspace. With that restriction the user should either
disable nested translation to favor RO stage-2 mappings or ensure no
RO stage-2 mapping to enable nested translation.
Intel-iommu driver is armed with necessary checks to prevent such mix
in patch12 of this series.
Qemu currently does add RO mappings though. The vfio agent in Qemu
simply maps all valid regions in the GPA address space which certainly
includes RO regions e.g. vbios.
In reality we don't know a usage relying on DMA reads from the BIOS
region. Hence finding a way to skip RO regions (e.g. via a discard manager)
in Qemu might be an acceptable tradeoff. The actual change needs more
discussion in Qemu community. For now we just hacked Qemu to test.
Complete code can be found in [3], corresponding QEMU could can be found
in [4].
[1] https://lore.kernel.org/linux-iommu/20230724110406.107212-1-yi.l.liu@intel.…
[2] https://www.intel.com/content/www/us/en/content-details/772415/content-deta…
[3] https://github.com/yiliu1765/iommufd/tree/iommufd_nesting
[4] https://github.com/yiliu1765/qemu/tree/wip/iommufd_rfcv4_nesting
Change log:
v4:
- Remove ascii art tables (Jason)
- Drop EMT (Tina, Jason)
- Drop MTS and related definitions (Kevin)
- Rename macro IOMMU_VTD_PGTBL_ to IOMMU_VTD_S1_ (Kevin)
- Rename struct iommu_hwpt_intel_vtd_ to iommu_hwpt_vtd_ (Kevin)
- Rename struct iommu_hwpt_intel_vtd to iommu_hwpt_vtd_s1 (Kevin)
- Put the vendor specific hwpt alloc data structure before enuma iommu_hwpt_type (Kevin)
- Do not trim the higher page levels of S2 domain in nested domain attachment as the
S2 domain may have been used independently. (Kevin)
- Remove the first-stage pgd check against the maximum address of s2_domain as hw
can check it anyhow. It makes sense to check every pfns used in the stage-1 page
table. But it cannot make it. So just leave it to hw. (Kevin)
- Split the iotlb flush part into an order of uapi, helper and callback implementation (Kevin)
- Change the policy of VT-d nesting errata, disallow RO mapping once a domain is used
as parent domain of a nested domain. This removes the nested_users counting. (Kevin)
- Minor fix for "make htmldocs"
v3: https://lore.kernel.org/linux-iommu/20230511145110.27707-1-yi.l.liu@intel.c…
- Further split the patches into an order of adding helpers for nested
domain, iotlb flush, nested domain attachment and nested domain allocation
callback, then report the hw_info to userspace.
- Add batch support in cache invalidation from userspace
- Disallow nested translation usage if RO mappings exists in stage-2 domain
due to errata on readonly mappings on Sapphire Rapids platform.
v2: https://lore.kernel.org/linux-iommu/20230309082207.612346-1-yi.l.liu@intel.…
- The iommufd infrastructure is split to be separate series.
v1: https://lore.kernel.org/linux-iommu/20230209043153.14964-1-yi.l.liu@intel.c…
Regards,
Yi Liu
Lu Baolu (5):
iommu/vt-d: Extend dmar_domain to support nested domain
iommu/vt-d: Add helper for nested domain allocation
iommu/vt-d: Add helper to setup pasid nested translation
iommu/vt-d: Add nested domain allocation
iommu/vt-d: Disallow nesting on domains with read-only mappings
Yi Liu (7):
iommufd: Add data structure for Intel VT-d stage-1 domain allocation
iommu/vt-d: Make domain attach helpers to be extern
iommu/vt-d: Set the nested domain to a device
iommufd: Add data structure for Intel VT-d stage-1 cache invalidation
iommu/vt-d: Make iotlb flush helpers to be extern
iommu/vt-d: Add iotlb flush for nested domain
iommu/vt-d: Implement hw_info for iommu capability query
drivers/iommu/intel/Makefile | 2 +-
drivers/iommu/intel/iommu.c | 80 +++++++++++++---
drivers/iommu/intel/iommu.h | 55 +++++++++--
drivers/iommu/intel/nested.c | 174 +++++++++++++++++++++++++++++++++++
drivers/iommu/intel/pasid.c | 127 +++++++++++++++++++++++++
drivers/iommu/intel/pasid.h | 2 +
drivers/iommu/iommufd/main.c | 6 ++
include/linux/iommu.h | 1 +
include/uapi/linux/iommufd.h | 124 +++++++++++++++++++++++++
9 files changed, 549 insertions(+), 22 deletions(-)
create mode 100644 drivers/iommu/intel/nested.c
--
2.34.1
Use RIP-relative addressing when setting `environ` and `_auxv` in
startup code.
Some toolchains have `-pie` enabled by default. On them or when -pie is
specified manually gcc produces error like this:
ld: /tmp/cci0uPcR.o: relocation R_X86_64_32S against symbol `environ' can not be used when making a PIE object; recompile with -fPIE
ld: failed to set dynamic section sizes: bad value
This is because asm() startup code accesses there pointers with absolute
addressing.
This may inspire others to fix the problem for other architectures too.
Signed-off-by: Vitaly Chikunov <vt(a)altlinux.org>
---
tools/include/nolibc/arch-x86_64.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/include/nolibc/arch-x86_64.h b/tools/include/nolibc/arch-x86_64.h
index 6fc4d8392742..a6be44b333ce 100644
--- a/tools/include/nolibc/arch-x86_64.h
+++ b/tools/include/nolibc/arch-x86_64.h
@@ -199,14 +199,14 @@ void __attribute__((weak,noreturn,optimize("omit-frame-pointer"))) __no_stack_pr
"pop %rdi\n" /* argc (first arg, %rdi) */
"mov %rsp, %rsi\n" /* argv[] (second arg, %rsi) */
"lea 8(%rsi,%rdi,8),%rdx\n" /* then a NULL then envp (third arg, %rdx) */
- "mov %rdx, environ\n" /* save environ */
+ "mov %rdx, environ(%rip)\n" /* save environ */
"xor %ebp, %ebp\n" /* zero the stack frame */
"mov %rdx, %rax\n" /* search for auxv (follows NULL after last env) */
"0:\n"
"add $8, %rax\n" /* search for auxv using rax, it follows the */
"cmp -8(%rax), %rbp\n" /* ... NULL after last env (rbp is zero here) */
"jnz 0b\n"
- "mov %rax, _auxv\n" /* save it into _auxv */
+ "mov %rax, _auxv(%rip)\n" /* save it into _auxv */
"and $-16, %rsp\n" /* x86 ABI : esp must be 16-byte aligned before call */
"call main\n" /* main() returns the status code, we'll exit with it. */
"mov %eax, %edi\n" /* retrieve exit code (32 bit) */
--
2.33.8
Hi all,
In the kernel 6.5-rc5 build on Ubuntu 22.04 LTS (jammy jellyfish) on a Ryzen 7950 assembled box,
vanilla torvalds tree kernel, the test test_unix_oob unexpectedly fails:
# selftests: net/af_unix: test_unix_oob
# Test 2 failed, sigurg 23 len 63 OOB %
It is this code:
/* Test 2:
* Verify that the first OOB is over written by
* the 2nd one and the first OOB is returned as
* part of the read, and sigurg is received.
*/
wait_for_data(pfd, POLLIN | POLLPRI);
len = 0;
while (len < 70)
len = recv(pfd, buf, 1024, MSG_PEEK);
len = read_data(pfd, buf, 1024);
read_oob(pfd, &oob);
if (!signal_recvd || len != 127 || oob != '#') {
fprintf(stderr, "Test 2 failed, sigurg %d len %d OOB %c\n",
signal_recvd, len, oob);
die(1);
}
In 6.5-rc4, this test was OK, so it might mean we have a regression?
marvin@defiant:~/linux/kernel/linux_torvalds$ grep test_unix_oob ../kselftest-6.5-rc4-1.log
/net/af_unix/test_unix_oob
# selftests: net/af_unix: test_unix_oob
ok 2 selftests: net/af_unix: test_unix_oob
marvin@defiant:~/linux/kernel/linux_torvalds$
Hope this helps.
NOTE: the kernel is vanilla torvalds tree, only "dirty" because the selftests were modified.
Kind regards,
Mirsad Todorovac
asm/current.h is included by some assembly files (either directly, or
indirectly). This works on some architectures (such as x86), as their
implementation of current.h is careful to not include any C, but the
asm-generic version includes linux/thread-info.h unconditionally, which
leads to errors when either C code or non-asm-compatible preprocessor
directives are included.
Just wrap the contents behind an #ifndef __ASSEMBLY__ to avoid any C
code making its way in.
Signed-off-by: David Gow <davidgow(a)google.com>
---
This is requrired for patch #2 here, as UML uses this asm-generic
header, but works with x86 assembly files which are expecting the x86
current.h, which is assembly-friendly.
---
include/asm-generic/current.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/asm-generic/current.h b/include/asm-generic/current.h
index 3a2e224b9fa0..9c2aeecbd05a 100644
--- a/include/asm-generic/current.h
+++ b/include/asm-generic/current.h
@@ -2,9 +2,11 @@
#ifndef __ASM_GENERIC_CURRENT_H
#define __ASM_GENERIC_CURRENT_H
+#ifndef __ASSEMBLY__
#include <linux/thread_info.h>
#define get_current() (current_thread_info()->task)
#define current get_current()
+#endif
#endif /* __ASM_GENERIC_CURRENT_H */
--
2.41.0.255.g8b1d071c50-goog
Greetings from Ukraine,
Mr. Razumkov Mykhailo, an entrepreneur businessman from Odessa
Ukraine. Within a year plus some months now, more than 8.2 million
people around the cities of my country Ukraine have been evacuated to
a safe location and out of the country, most especially children with
their parents, nursing mothers and pregnant women, and those who have
been seriously wounded and need urgent medical attention. I was among
those that were able to evacuate to our neighbouring countries and I’m
now in the refugee camp of Ter Apel Groningen in the Netherlands.
I need a foreign partner to enable me to transport my investment
capital and then relocate with my family, honestly i wish I will
discuss more and get along. I need a partner because my investment
capital is in my international account. I’m interested in buying
properties, houses, building real estates, my capital for investment
is ($30 Million USD) . The financial institutions in my country
Ukraine are all shot down due to the crisis of this war on Ukraine
soil by the Russian forces. Meanwhile, if there is any profitable
investment that you have so much experience in your country, then we
can join together as partners since I’m a foreigner.
I came across your e-mail contact through private search while in need
of your assistance and I decided to contact you directly to ask you if
you know any lucrative business investment in your country i can
invest my money since my country Ukraine security and economic
independent has lost to the greatest lower level, and our culture has
lost including our happiness has been taken away from us. Our country
has been on fire for more than a year now.
If you are capable of handling this business partnership, contact me
for more details, I will appreciate it if you can contact me
immediately. You may as well tell me a little more about yourself.
Contact me urgently to enable us to proceed with the business. I will
be waiting for your response. My sincere apologies for the
inconvenience.
Thank you!
Mr. Razumkov Mykhailo.
From commit ebf7d1f508a73871 ("bpf, x64: rework pro/epilogue and tailcall
handling in JIT"), the tailcall on x64 works better than before.
From commit e411901c0b775a3a ("bpf: allow for tailcalls in BPF subprograms
for x64 JIT"), tailcall is able to run in BPF subprograms on x64.
From commit 5b92a28aae4dd0f8 ("bpf: Support attaching tracing BPF program
to other BPF programs"), BPF program is able to trace other BPF programs.
How about combining them all together?
1. FENTRY/FEXIT on a BPF subprogram.
2. A tailcall runs in the BPF subprogram.
3. The tailcall calls itself.
As a result, a tailcall infinite loop comes up. And the loop would halt
the machine.
As we know, in tail call context, the tail_call_cnt propagates by stack
and RAX register between BPF subprograms. So do it in FENTRY/FEXIT
trampolines.
How did I discover the bug?
From commit 7f6e4312e15a5c37 ("bpf: Limit caller's stack depth 256 for
subprogs with tailcalls"), the total stack size limits to around 8KiB.
Then, I write some bpf progs to validate the stack consuming, that are
tailcalls running in bpf2bpf and FENTRY/FEXIT tracing on bpf2bpf[1].
At that time, accidently, I made a tailcall loop. And then the loop halted
my VM. Without the loop, the bpf progs would consume over 8KiB stack size.
But the _stack-overflow_ did not halt my VM.
With bpf_printk(), I confirmed that the tailcall count limit did not work
expectedly. Next, read the code and fix it.
Finally, unfortunately, I only fix it on x64 but other arches. As a
result, CI tests failed because this bug hasn't been fixed on s390x.
Some helps are requested.
[1]: https://github.com/Asphaltt/learn-by-example/tree/main/ebpf/tailcall-stacko…
Leon Hwang (2):
bpf, x64: Fix tailcall infinite loop bug
selftests/bpf: Add testcases for tailcall infinite loop bug fixing
arch/x86/net/bpf_jit_comp.c | 23 ++-
include/linux/bpf.h | 6 +
kernel/bpf/trampoline.c | 5 +-
kernel/bpf/verifier.c | 9 +-
.../selftests/bpf/prog_tests/tailcalls.c | 194 +++++++++++++++++-
.../bpf/progs/tailcall_bpf2bpf_fentry.c | 18 ++
.../bpf/progs/tailcall_bpf2bpf_fexit.c | 18 ++
7 files changed, 264 insertions(+), 9 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_fentry.c
create mode 100644 tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_fexit.c
base-commit: 9930e4af4b509bcf6f060b09b16884f26102d110
--
2.41.0
The hwcaps selftest currently relies on the assembler being able to
assemble the crc32w instruction but this is not in the base v8.0 so is not
accepted by the standard GCC configurations used by many distributions.
Switch to manually encoding to fix the build.
Fixes: 09d2e95a04ad ("kselftest/arm64: add crc32 feature to hwcap test")
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/abi/hwcap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
index 112b6a219382..3b26a3660292 100644
--- a/tools/testing/selftests/arm64/abi/hwcap.c
+++ b/tools/testing/selftests/arm64/abi/hwcap.c
@@ -42,7 +42,8 @@ static void atomics_sigill(void)
static void crc32_sigill(void)
{
- asm volatile("crc32w w0, w0, w1");
+ /* CRC32W W0, W0, W1 */
+ asm volatile(".inst 0x1ac14800" : : : );
}
static void cssc_sigill(void)
---
base-commit: 358b763ee64b11f45287c286e1f6145729ed49ab
change-id: 20230816-arm64-fix-crc32-build-9d4c94f2e60e
Best regards,
--
Mark Brown <broonie(a)kernel.org>
lwt xmit hook does not expect positive return values in function
ip_finish_output2 and ip6_finish_output. However, BPF programs can
directly return positive statuses such like NET_XMIT_DROP, NET_RX_DROP,
and etc to the caller. Such return values would make the kernel continue
processing already freed skbs and eventually panic.
This set fixes the return values from BPF ops to unexpected continue
processing, checks strictly on the correct continue condition for
future proof. In addition, add missing selftests for BPF redirect
and reroute cases for BPF-CI.
v5: https://lore.kernel.org/bpf/cover.1692153515.git.yan@cloudflare.com/
v4: https://lore.kernel.org/bpf/ZMD1sFTW8SFiex+x@debian.debian/T/
v3: https://lore.kernel.org/bpf/cover.1690255889.git.yan@cloudflare.com/
v2: https://lore.kernel.org/netdev/ZLdY6JkWRccunvu0@debian.debian/
v1: https://lore.kernel.org/bpf/ZLbYdpWC8zt9EJtq@debian.debian/
changes since v5:
* fix BPF-CI failures due to missing config and busybox ping issue
changes since v4:
* fixed same error on BPF_REROUTE path
* re-implemented selftests under BPF-CI requirement
changes since v3:
* minor change in commit message and changelogs
* tested by Jakub Sitnicki
changes since v2:
* subject name changed
* also covered redirect to ingress case
* added selftests
changes since v1:
* minor code style changes
Yan Zhai (4):
lwt: fix return values of BPF xmit ops
lwt: check LWTUNNEL_XMIT_CONTINUE strictly
selftests/bpf: add lwt_xmit tests for BPF_REDIRECT
selftests/bpf: add lwt_xmit tests for BPF_REROUTE
include/net/lwtunnel.h | 5 +-
net/core/lwt_bpf.c | 7 +-
net/ipv4/ip_output.c | 2 +-
net/ipv6/ip6_output.c | 2 +-
tools/testing/selftests/bpf/config | 2 +
.../selftests/bpf/prog_tests/lwt_helpers.h | 139 ++++++++
.../selftests/bpf/prog_tests/lwt_redirect.c | 330 ++++++++++++++++++
.../selftests/bpf/prog_tests/lwt_reroute.c | 262 ++++++++++++++
.../selftests/bpf/progs/test_lwt_redirect.c | 90 +++++
.../selftests/bpf/progs/test_lwt_reroute.c | 36 ++
10 files changed, 868 insertions(+), 7 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_helpers.h
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_redirect.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_reroute.c
create mode 100644 tools/testing/selftests/bpf/progs/test_lwt_redirect.c
create mode 100644 tools/testing/selftests/bpf/progs/test_lwt_reroute.c
--
2.30.2
iommufd gives userspace the capability to manipulate iommu subsytem.
e.g. DMA map/unmap etc. In the near future, it will support iommu nested
translation. Different platform vendors have different implementations for
the nested translation. For example, Intel VT-d supports using guest I/O
page table as the stage-1 translation table. This requires guest I/O page
table be compatible with hardware IOMMU. So before set up nested translation,
userspace needs to know the hardware iommu information to understand the
nested translation requirements.
This series reports the iommu hardware information for a given device
which has been bound to iommufd. It is preparation work for userspace to
allocate hwpt for given device. Like the nested translation support [1].
This series introduces an iommu op to report the iommu hardware info,
and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to
user. enum iommu_hw_info_type is defined to differentiate the iommu hardware
info reported to user hence user can decode them. This series adds the
framework for iommu hw info reporting, and adds the vtd implementation. The
complete code is available in [2].
[1] https://lore.kernel.org/linux-iommu/20230724110406.107212-1-yi.l.liu@intel.…
[2] https://github.com/yiliu1765/iommufd/tree/iommufd_hw_info-v9
Change log:
v9:
- Simplify kdoc and updated commit logs
- Minor changes in iommufd_get_hw_info() from Kevin's review comments
- Add a selftest coverage for passing in a smaller buffer
- Add Kevin's r-b to patch 02/03/05.
v8: https://lore.kernel.org/linux-iommu/20230816121349.104436-1-yi.l.liu@intel.…
- Updated the uAPI by allowing a 0 value at the input @data_len
- Changed to always report the kernel supported data length instead of the
length that kernel filled in the user space buffer
- Updated uAPI doc accordingly
- Add one more selftest for 0 value @data_len and also check the output @data_len
with the size kernel supports
- Fix the usage of clear_user()
- Rebase on top of Jason's for-next branch (base: 65aaca1 iommufd: Remove iommufd_ref_to_users())
- Include the vtd hw_info implementation from vtd nesting series
https://lore.kernel.org/r/20230724111335.107427-12-yi.l.liu@intel.com
v7: https://lore.kernel.org/linux-iommu/20230811071501.4126-1-yi.l.liu@intel.co…
- Use clear_user() (Jason)
- Add fail_nth for hw_ifo (Jason)
v6: https://lore.kernel.org/linux-iommu/20230808153510.4170-1-yi.l.liu@intel.co…
- Add Jingqi's comment on patch 02
- Add Baolu's r-b to patch 03
- Address Jason's comment on patch 03
v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.…
- Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin)
- Add Jason's r-b for patch 01
- Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04
v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.…
- Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info
- Move the iommufd_get_hw_info handler to main.c
- Place iommu_hw_info prior to iommu_hwpt_alloc
- Update the function namings accordingly
- Update uapi kdocs
v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.c…
- Add r-b from Baolu
- Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to
better suit what it means
- Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver
does not have driver-specific data to report per below remark.
https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/
v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.…
- Drop patch 05 of v1 as it is already covered by other series
- Rename the capability info to be iommu hardware info
v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.co…
Regards,
Yi Liu
Lu Baolu (1):
iommu: Add new iommu op to get iommu hardware information
Nicolin Chen (1):
iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl
Yi Liu (3):
iommu: Move dev_iommu_ops() to private header
iommufd: Add IOMMU_GET_HW_INFO
iommu/vt-d: Implement hw_info for iommu capability query
drivers/iommu/intel/iommu.c | 19 +++++
drivers/iommu/iommu-priv.h | 11 +++
drivers/iommu/iommufd/device.c | 73 +++++++++++++++++++
drivers/iommu/iommufd/iommufd_private.h | 1 +
drivers/iommu/iommufd/iommufd_test.h | 9 +++
drivers/iommu/iommufd/main.c | 3 +
drivers/iommu/iommufd/selftest.c | 16 ++++
include/linux/iommu.h | 16 ++--
include/uapi/linux/iommufd.h | 71 ++++++++++++++++++
tools/testing/selftests/iommu/iommufd.c | 38 +++++++++-
.../selftests/iommu/iommufd_fail_nth.c | 4 +
tools/testing/selftests/iommu/iommufd_utils.h | 62 ++++++++++++++++
12 files changed, 311 insertions(+), 12 deletions(-)
--
2.34.1
As is described in the "How to use MPTCP?" section in MPTCP wiki [1]:
"Your app should create sockets with IPPROTO_MPTCP as the proto:
( socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP); ). Legacy apps can be
forced to create and use MPTCP sockets instead of TCP ones via the
mptcpize command bundled with the mptcpd daemon."
But the mptcpize (LD_PRELOAD technique) command has some limitations
[2]:
- it doesn't work if the application is not using libc (e.g. GoLang
apps)
- in some envs, it might not be easy to set env vars / change the way
apps are launched, e.g. on Android
- mptcpize needs to be launched with all apps that want MPTCP: we could
have more control from BPF to enable MPTCP only for some apps or all the
ones of a netns or a cgroup, etc.
- it is not in BPF, we cannot talk about it at netdev conf.
So this patchset attempts to use BPF to implement functions similer to
mptcpize.
The main idea is to add a hook in sys_socket() to change the protocol id
from IPPROTO_TCP (or 0) to IPPROTO_MPTCP.
[1]
https://github.com/multipath-tcp/mptcp_net-next/wiki
[2]
https://github.com/multipath-tcp/mptcp_net-next/issues/79
v14:
- Use getsockopt(MPTCP_INFO) to verify mptcp protocol intead of using
nstat command.
v13:
- drop "Use random netns name for mptcp" patch.
v12:
- update diag_* log of update_socket_protocol.
- add 'ip netns show' after 'ip netns del' to check if there is
a test did not clean up its netns.
- return libbpf_get_error() instead of -EIO for the error from
open_and_load().
- Use getsockopt(SOL_PROTOCOL) to verify mptcp protocol intead of
using 'ss -tOni'.
v11:
- add comments about outputs of 'ss' and 'nstat'.
- use "err = verify_mptcpify()" instead of using =+.
v10:
- drop "#ifdef CONFIG_BPF_JIT".
- include vmlinux.h and bpf_tracing_net.h to avoid defining some
macros.
- drop unneeded checks for mptcp.
v9:
- update comment for 'update_socket_protocol'.
v8:
- drop the additional checks on the 'protocol' value after the
'update_socket_protocol()' call.
v7:
- add __weak and __diag_* for update_socket_protocol.
v6:
- add update_socket_protocol.
v5:
- add bpf_mptcpify helper.
v4:
- use lsm_cgroup/socket_create
v3:
- patch 8: char cmd[128]; -> char cmd[256];
v2:
- Fix build selftests errors reported by CI
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/79
Geliang Tang (4):
bpf: Add update_socket_protocol hook
selftests/bpf: Add two mptcp netns helpers
selftests/bpf: Fix error checks of mptcp open_and_load
selftests/bpf: Add mptcpify test
net/mptcp/bpf.c | 15 ++
net/socket.c | 26 ++-
.../testing/selftests/bpf/prog_tests/mptcp.c | 155 +++++++++++++++---
tools/testing/selftests/bpf/progs/mptcpify.c | 20 +++
4 files changed, 196 insertions(+), 20 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/mptcpify.c
--
2.35.3
Dzień dobry,
Czy interesuje Państwa rozwiązanie umożliwiające monitorowanie samochodów firmowych oraz optymalizację kosztów ich utrzymania?
Pozdrawiam,
Jakub Lemczak
The benchmark command handling (-b) in resctrl selftests is overly
complicated code. This series turns the benchmark command immutable to
preserve it for all selftests and improves benchmark command related
error handling.
This series also ends up removing the strcpy() calls which were pointed
out earlier.
Ilpo Järvinen (7):
selftests/resctrl: Ensure the benchmark commands fits to its array
selftests/resctrl: Correct benchmark command help
selftests/resctrl: Remove bw_report and bm_type from main()
selftests/resctrl: Simplify span lifetime
selftests/resctrl: Use pointers to build benchmark cmd and make it
const
selftests/resctrl: remove ben_count variable
selftests/resctrl: Cleanup benchmark argument parsing
tools/testing/selftests/resctrl/cache.c | 5 +-
tools/testing/selftests/resctrl/cat_test.c | 13 +--
tools/testing/selftests/resctrl/cmt_test.c | 32 +++++--
tools/testing/selftests/resctrl/mba_test.c | 4 +-
tools/testing/selftests/resctrl/mbm_test.c | 7 +-
tools/testing/selftests/resctrl/resctrl.h | 22 +++--
.../testing/selftests/resctrl/resctrl_tests.c | 88 ++++++++-----------
tools/testing/selftests/resctrl/resctrl_val.c | 10 ++-
8 files changed, 98 insertions(+), 83 deletions(-)
--
2.30.2
iommufd gives userspace the capability to manipulate iommu subsytem.
e.g. DMA map/unmap etc. In the near future, it will support iommu nested
translation. Different platform vendors have different implementations for
the nested translation. For example, Intel VT-d supports using guest I/O
page table as the stage-1 translation table. This requires guest I/O page
table be compatible with hardware IOMMU. So before set up nested translation,
userspace needs to know the hardware iommu information to understand the
nested translation requirements.
This series reports the iommu hardware information for a given device
which has been bound to iommufd. It is preparation work for userspace to
allocate hwpt for given device. Like the nested translation support[1].
This series introduces an iommu op to report the iommu hardware info,
and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to
user. enum iommu_hw_info_type is defined to differentiate the iommu hardware
info reported to user hence user can decode them. This series adds the
framework for iommu hw info reporting, and adds the vtd implementation. The
complete code is available in [1].
[1] https://github.com/yiliu1765/iommufd/tree/iommufd_hw_info-v8
Change log:
v8:
- Updated the uAPI by allowing a 0 value at the input @data_len
- Changed to always report the kernel supported data length instead of the
length that kernel filled in the user space buffer
- Updated uAPI doc accordingly
- Add one more selftest for 0 value @data_len and also check the output @data_len
with the size kernel supports
- Fix the usage of clear_user()
- Rebase on top of Jason's for-next branch (base: 65aaca1 iommufd: Remove iommufd_ref_to_users())
- Include the vtd hw_info implementation from vtd nesting series
https://lore.kernel.org/r/20230724111335.107427-12-yi.l.liu@intel.com
v7: https://lore.kernel.org/linux-iommu/20230811071501.4126-1-yi.l.liu@intel.co…
- Use clear_user() (Jason)
- Add fail_nth for hw_ifo (Jason)
v6: https://lore.kernel.org/linux-iommu/20230808153510.4170-1-yi.l.liu@intel.co…
- Add Jingqi's comment on patch 02
- Add Baolu's r-b to patch 03
- Address Jason's comment on patch 03
v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.…
- Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin)
- Add Jason's r-b for patch 01
- Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04
v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.…
- Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info
- Move the iommufd_get_hw_info handler to main.c
- Place iommu_hw_info prior to iommu_hwpt_alloc
- Update the function namings accordingly
- Update uapi kdocs
v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.c…
- Add r-b from Baolu
- Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to
better suit what it means
- Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver
does not have driver-specific data to report per below remark.
https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/
v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.…
- Drop patch 05 of v1 as it is already covered by other series
- Rename the capability info to be iommu hardware info
v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.co…
Regards,
Yi Liu
Lu Baolu (1):
iommu: Add new iommu op to get iommu hardware information
Nicolin Chen (1):
iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl
Yi Liu (3):
iommu: Move dev_iommu_ops() to private header
iommufd: Add IOMMU_GET_HW_INFO
iommu/vt-d: Implement hw_info for iommu capability query
drivers/iommu/intel/iommu.c | 19 +++++
drivers/iommu/iommu-priv.h | 11 +++
drivers/iommu/iommufd/device.c | 73 ++++++++++++++++++
drivers/iommu/iommufd/iommufd_private.h | 1 +
drivers/iommu/iommufd/iommufd_test.h | 9 +++
drivers/iommu/iommufd/main.c | 3 +
drivers/iommu/iommufd/selftest.c | 16 ++++
include/linux/iommu.h | 20 +++--
include/uapi/linux/iommufd.h | 74 +++++++++++++++++++
tools/testing/selftests/iommu/iommufd.c | 30 +++++++-
.../selftests/iommu/iommufd_fail_nth.c | 4 +
tools/testing/selftests/iommu/iommufd_utils.h | 56 ++++++++++++++
12 files changed, 304 insertions(+), 12 deletions(-)
--
2.34.1
Hi,
This patch series aims to improve the PMU event filter settings with a cleaner
and more organized structure and adds several test cases related to PMU event
filters.
These changes help to ensure that KVM's PMU event filter functions as expected
in all supported use cases.
Any feedback or suggestions are greatly appreciated.
Sincerely,
Jinrong Liang
Changes log:
v6:
- Rebased to 74c2185c5b74(tag: kvm-x86-next-2023.08.02);
- Use TEST_ASSERT_EQ() instead of ASSERT_EQ();
- Fix a bug about x86 properties for Intel PMU in patch v5;
v5:
https://lore.kernel.org/kvm/20230720114714.34079-1-cloudliang@tencent.com/T/
Jinrong Liang (6):
KVM: selftests: Add x86 properties for Intel PMU in processor.h
KVM: selftests: Drop the return of remove_event()
KVM: selftests: Introduce __kvm_pmu_event_filter to improved event
filter settings
KVM: selftests: Add test cases for unsupported PMU event filter input
values
KVM: selftests: Test if event filter meets expectations on fixed
counters
KVM: selftests: Test gp event filters don't affect fixed event filters
.../selftests/kvm/include/x86_64/processor.h | 5 +
.../kvm/x86_64/pmu_event_filter_test.c | 317 ++++++++++++------
2 files changed, 228 insertions(+), 94 deletions(-)
base-commit: 74c2185c5b74fd0ae91133ad5afe8684f6a02b91
--
2.39.3
Add parameter descriptions to struct kunit_attr header for the
parameters attr_default and print.
Fixes: 39e92cb1e4a1 ("kunit: Add test attributes API structure")
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308180127.VD7YRPGa-lkp@intel.com/
Signed-off-by: Rae Moar <rmoar(a)google.com>
---
lib/kunit/attributes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/kunit/attributes.c b/lib/kunit/attributes.c
index 5e3034b6be99..1b512f7e1838 100644
--- a/lib/kunit/attributes.c
+++ b/lib/kunit/attributes.c
@@ -30,6 +30,8 @@ enum print_ops {
* attribute value
* @filter: function to indicate whether a given attribute value passes a
* filter
+ * @attr_default: default attribute value used during filtering
+ * @print: value of enum print_ops to indicate when to print attribute
*/
struct kunit_attr {
const char *name;
base-commit: 582eb3aeed2d06b122fba95518b84506d3d4ceb9
--
2.42.0.rc1.204.g551eb34607-goog
I ran all kernel selftests on some test machine, and stumbled upon
cachestat failing (among others).
Those patches fix the cachestat test compilation and run on older
kernels.
Also I found that the but-last test (on a normal file) fails when run on
a tmpfs mounted directory, as it happens on an initramfs-only system, or
when the current directory happens to be /dev/shm or /tmp:
# Create/open tmpfilecachestat
# Cachestat call returned 0
# Using cachestat: Cached: 4, Dirty: 4, Writeback: 0, Evicted: 0, Recently Evicted: 0
# Cachestat call (after fsync) returned 0
# Using cachestat: Cached: 4, Dirty: 4, Writeback: 0, Evicted: 0, Recently Evicted: 0
# Number of dirty should be zero after fsync.
not ok 6 cachestat fails with normal file
That same test binary succeeds on the same machine right afterwards if
the current directory is changed to an ext4 filesystem.
I don't really know if this is expected, and whether we should try to
figure out if the test file lives on a tmpfs filesystem, or whether the
test itself is not strict enough, and requires more "flushing"
(drop_caches?) to cover tmpfs directories as well.
Any ideas how to fix this would be appreciated.
Cheers,
Andre
Andre Przywara (3):
selftests: cachestat: properly link in librt
selftests: cachestat: use proper syscall number macro
selftests: cachestat: test for cachestat availability
tools/testing/selftests/cachestat/Makefile | 2 +-
.../selftests/cachestat/test_cachestat.c | 29 +++++++++++++++----
2 files changed, 25 insertions(+), 6 deletions(-)
--
2.25.1
Regressions that cause a device to no longer be probed by a driver can
have a big impact on the platform's functionality, and despite being
relatively common there isn't currently any generic test to detect them.
As an example, bootrr [1] does test for device probe, but it requires
defining the expected probed devices for each platform.
Given that the Devicetree already provides a static description of
devices on the system, it is a good basis for building such a test on
top.
This series introduces a test to catch regressions that prevent devices
from probing.
Patch 1 introduces a script to parse the kernel source using Coccinelle
and extract all compatibles that can be matched by a Devicetree node to
a driver. Patch 2 adds a kselftest that walks over the Devicetree nodes
on the current platform and compares the compatibles to the ones on the
list, and on an ignore list, to point out devices that failed to be
probed.
A compatible list is needed because not all compatibles that can show up
in a Devicetree node can be used to match to a driver, for example the
code for that compatible might use "OF_DECLARE" type macros and avoid
the driver framework, or the node might be controlled by a driver that
was bound to a different node.
An ignore list is needed for the few cases where it's common for a
driver to match a device but not probe, like for the "simple-mfd"
compatible, where the driver only probes if that compatible is the
node's first compatible.
Even though there's already scripts/dtc/dt-extract-compatibles that does
a similar job, it didn't seem to find all compatibles, returning ~3k,
while Coccinelle found ~11k. Besides that, Coccinelle actually parses
the C files, so it should be a more robust solution than relying on
regexes.
The reason for parsing the kernel source instead of relying on
information exposed by the kernel at runtime (say, looking at modaliases
or introducing some other mechanism), is to be able to catch issues
where a config was renamed or a driver moved across configs, and the
.config used by the kernel not updated accordingly. We need to parse the
source to find all compatibles present in the kernel independent of the
current config being run.
Feedback is very much welcome.
Thanks,
Nícolas
[1] https://github.com/kernelci/bootrr
Nícolas F. R. A. Prado (2):
scripts/dtc: Add script to extract matchable DT compatibles
kselftest: Add Devicetree unprobed devices test
scripts/dtc/extract-matchable-dt-compatibles | 33 +++++++++++
scripts/dtc/matchable_dt_compatibles.cocci | 58 +++++++++++++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/dt/.gitignore | 1 +
tools/testing/selftests/dt/Makefile | 17 ++++++
.../selftests/dt/compatible_ignore_list | 3 +
.../selftests/dt/test_unprobed_devices.sh | 58 +++++++++++++++++++
7 files changed, 171 insertions(+)
create mode 100755 scripts/dtc/extract-matchable-dt-compatibles
create mode 100644 scripts/dtc/matchable_dt_compatibles.cocci
create mode 100644 tools/testing/selftests/dt/.gitignore
create mode 100644 tools/testing/selftests/dt/Makefile
create mode 100644 tools/testing/selftests/dt/compatible_ignore_list
create mode 100755 tools/testing/selftests/dt/test_unprobed_devices.sh
--
2.41.0
When naively running all kselftests on some systems, it was observed
that the landlock selftest is quite picky and reports failures, even
though the system is fine.
Those two patches relax some tests to make them pass on older kernels:
- The landlock ABI version is only "3" in recent kernels, so patch 1/2
relaxes the test to accept other numbers.
- Older kernels or some defconfig based kernels might not implement
the landlock syscall at all. Patch 2/2 catches this.
I couldn't find an easy way to not check for the syscall availability in
*every* test in base_test.c, short of not using TEST_HARNESS_MAIN at all.
If someone has a better idea, I am all ears, especially as this approach
will get quite annoying in fs_base.c.
Cheers,
Andre
Andre Przywara (2):
selftests: landlock: allow other ABI versions
selftests: landlock: skip all tests without landlock syscall
tools/testing/selftests/landlock/base_test.c | 29 +++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
--
2.25.1
While building selftests landlock following warnings / errors noticed on the
Linux next with clang-17 toolchain.
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
Build errors:
------------
timens/timerfd
timerfd.c:64:7: error: absolute value function 'abs' given an argument
of type 'long long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
64 | if (abs(elapsed - 3600) > 60) {
| ^
timerfd.c:64:7: note: use function 'llabs' instead
64 | if (abs(elapsed - 3600) > 60) {
| ^~~
| llabs
1 error generated.
make[4]: Leaving directory 'selftests/timens'
Links:
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2U69ue7AaypfY7eRU4UU…
Steps to reproduce:
tuxmake --runtime podman --target-arch arm64 --toolchain clang-17
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2U69ue7AaypfY7eRU4UU…
LLVM=1 LLVM_IAS=1 dtbs dtbs-legacy headers kernel kselftest modules
--
Linaro LKFT
https://lkft.linaro.org
Adds a check to verify if the rtc device file is valid or not
and prints a useful error message if the file is not accessible.
Signed-off-by: Atul Kumar Pant <atulpant.linux(a)gmail.com>
---
changes since v4:
Updated the commit message.
changes since v3:
Added Linux-kselftest and Linux-kernel mailing lists.
changes since v2:
Changed error message when rtc file does not exist.
changes since v1:
Removed check for uid=0
If rtc file is invalid, then exit the test.
tools/testing/selftests/rtc/rtctest.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rtc/rtctest.c b/tools/testing/selftests/rtc/rtctest.c
index 63ce02d1d5cc..630fef735c7e 100644
--- a/tools/testing/selftests/rtc/rtctest.c
+++ b/tools/testing/selftests/rtc/rtctest.c
@@ -17,6 +17,7 @@
#include <unistd.h>
#include "../kselftest_harness.h"
+#include "../kselftest.h"
#define NUM_UIE 3
#define ALARM_DELTA 3
@@ -419,6 +420,8 @@ __constructor_order_last(void)
int main(int argc, char **argv)
{
+ int ret = -1;
+
switch (argc) {
case 2:
rtc_file = argv[1];
@@ -430,5 +433,11 @@ int main(int argc, char **argv)
return 1;
}
- return test_harness_run(argc, argv);
+ // Run the test if rtc_file is valid
+ if (access(rtc_file, F_OK) == 0)
+ ret = test_harness_run(argc, argv);
+ else
+ ksft_exit_fail_msg("[ERROR]: Cannot access rtc file %s - Exiting\n", rtc_file);
+
+ return ret;
}
--
2.25.1
From: Rong Tao <rongtao(a)cestc.cn>
Static ksyms often have problems because the number of symbols exceeds the
MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in
commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves
the problem somewhat, but it's not the perfect way.
This commit uses dynamic memory allocation, which completely solves the
problem caused by the limitation of the number of kallsyms.
Acked-by: Stanislav Fomichev <sdf(a)google.com>
Signed-off-by: Rong Tao <rongtao(a)cestc.cn>
---
v4: Make sure most cases we don't need the realloc() path to begin with,
and check strdup() return value.
v3: https://lore.kernel.org/lkml/tencent_50B4B2622FE7546A5FF9464310650C008509@q…
Do not use structs and judge ksyms__add_symbol function return value.
v2: https://lore.kernel.org/lkml/tencent_B655EE5E5D463110D70CD2846AB3262EED09@q…
Do the usual len/capacity scheme here to amortize the cost of realloc, and
don't free symbols.
v1: https://lore.kernel.org/lkml/tencent_AB461510B10CD484E0B2F62E3754165F2909@q…
---
tools/testing/selftests/bpf/trace_helpers.c | 46 ++++++++++++++++-----
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c
index f83d9f65c65b..a1461508925e 100644
--- a/tools/testing/selftests/bpf/trace_helpers.c
+++ b/tools/testing/selftests/bpf/trace_helpers.c
@@ -18,10 +18,35 @@
#define TRACEFS_PIPE "/sys/kernel/tracing/trace_pipe"
#define DEBUGFS_PIPE "/sys/kernel/debug/tracing/trace_pipe"
-#define MAX_SYMS 400000
-static struct ksym syms[MAX_SYMS];
+static struct ksym *syms;
+static int sym_cap;
static int sym_cnt;
+static int ksyms__add_symbol(const char *name, unsigned long addr)
+{
+ void *tmp;
+ unsigned int new_cap;
+
+ if (sym_cnt + 1 > sym_cap) {
+ new_cap = sym_cap * 4 / 3;
+ tmp = realloc(syms, sizeof(struct ksym) * new_cap);
+ if (!tmp)
+ return -ENOMEM;
+ syms = tmp;
+ sym_cap = new_cap;
+ }
+
+ tmp = strdup(name);
+ if (!tmp)
+ return -ENOMEM;
+ syms[sym_cnt].addr = addr;
+ syms[sym_cnt].name = tmp;
+
+ sym_cnt++;
+
+ return 0;
+}
+
static int ksym_cmp(const void *p1, const void *p2)
{
return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr;
@@ -33,9 +58,14 @@ int load_kallsyms_refresh(void)
char func[256], buf[256];
char symbol;
void *addr;
- int i = 0;
+ int ret;
+ /* Make sure most cases we don't need the realloc() path to begin with */
+ sym_cap = 400000;
sym_cnt = 0;
+ syms = malloc(sizeof(struct ksym) * sym_cap);
+ if (!syms)
+ return -ENOMEM;
f = fopen("/proc/kallsyms", "r");
if (!f)
@@ -46,15 +76,11 @@ int load_kallsyms_refresh(void)
break;
if (!addr)
continue;
- if (i >= MAX_SYMS)
- return -EFBIG;
-
- syms[i].addr = (long) addr;
- syms[i].name = strdup(func);
- i++;
+ ret = ksyms__add_symbol(func, (unsigned long)addr);
+ if (ret)
+ return ret;
}
fclose(f);
- sym_cnt = i;
qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp);
return 0;
}
--
2.39.3
The func_traceonoff_triggers.tc sometimes goes to fail
on my board, Kunpeng-920.
[root@localhost]# ./ftracetest ./test.d/ftrace/func_traceonoff_triggers.tc -l fail.log
=== Ftrace unit tests ===
[1] ftrace - test for function traceon/off triggers [FAIL]
[2] (instance) ftrace - test for function traceon/off triggers [UNSUPPORTED]
I look up the log, and it shows that the md5sum is different between csum1 and csum2.
++ cnt=611
++ sleep .1
+++ cnt_trace
+++ grep -v '^#' trace
+++ wc -l
++ cnt2=611
++ '[' 611 -ne 611 ']'
+++ cat tracing_on
++ on=0
++ '[' 0 '!=' 0 ']'
+++ md5sum trace
++ csum1='76896aa74362fff66a6a5f3cf8a8a500 trace'
++ sleep .1
+++ md5sum trace
++ csum2='ee8625a21c058818fc26e45c1ed3f6de trace'
++ '[' '76896aa74362fff66a6a5f3cf8a8a500 trace' '!=' 'ee8625a21c058818fc26e45c1ed3f6de trace' ']'
++ fail 'Tracing file is still changing'
++ echo Tracing file is still changing
Tracing file is still changing
++ exit_fail
++ exit 1
So I directly dump the trace file before md5sum, the diff shows that:
[root@localhost]# diff trace_1.log trace_2.log -y --suppress-common-lines
dockerd-12285 [036] d.... 18385.510290: sched_stat | <...>-12285 [036] d.... 18385.510290: sched_stat
dockerd-12285 [036] d.... 18385.510291: sched_swit | <...>-12285 [036] d.... 18385.510291: sched_swit
<...>-740 [044] d.... 18385.602859: sched_stat | kworker/44:1-740 [044] d.... 18385.602859: sched_stat
<...>-740 [044] d.... 18385.602860: sched_swit | kworker/44:1-740 [044] d.... 18385.602860: sched_swit
And we can see that the saved_cmdlines in kernel was changed.
So Maybe there is no safe to use md5sum here to verify whether
the file whether it has changed.
From my point of view, we only need to verify traceoff event
is valid there.
Maybe it is enough to check first that the tracing_on equals 0,
and then check that the total number of rows of trace does not
increase?
Fixes: d87b29179aa0 ("selftests: ftrace: Use md5sum to take less time of checking logs")
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
.../test.d/ftrace/func_traceonoff_triggers.tc | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
index aee22289536b..180c60605d7b 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
@@ -77,25 +77,17 @@ if [ $cnt -ne 1 ]; then
fail "Did not find traceoff trigger"
fi
-cnt=`cnt_trace`
-sleep $SLEEP_TIME
-cnt2=`cnt_trace`
-
-if [ $cnt -ne $cnt2 ]; then
- fail "Tracing is not stopped"
-fi
-
on=`cat tracing_on`
if [ $on != "0" ]; then
fail "Tracing is not off"
fi
-csum1=`md5sum trace`
+cnt=`cnt_trace`
sleep $SLEEP_TIME
-csum2=`md5sum trace`
+cnt2=`cnt_trace`
-if [ "$csum1" != "$csum2" ]; then
- fail "Tracing file is still changing"
+if [ $cnt -ne $cnt2 ]; then
+ fail "Tracing is not stopped"
fi
clear_trace
--
2.34.1
When debugging, it can be difficult to quickly find the ftrace dump
within the console log, which in turn makes it difficult to process it
independent of the result of the console output. This commit therefore
copies the contents of the buffers into its own file to make it easier
to locate and process the ftrace dump. The original ftrace dump is still
available in the console log in cases where it is more convenient to
process it there, for example, when you have a script that processes
console output as well as ftrace-dump data.
Also handle the case of multiple ftrace dumps potentially showing up in the
log. Example for a file like [1], it will extract as [2].
[1]:
foo
foo
Dumping ftrace buffer:
---------------------------------
blah
blah
---------------------------------
more
bar
baz
Dumping ftrace buffer:
---------------------------------
blah2
blah2
---------------------------------
bleh
bleh
[2]:
Ftrace dump 1:
blah
blah
Ftrace dump 2:
blah2
blah2
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org>
---
v2->v3: Updates from Paul. Also handle multiple ftrace dumps.
.../selftests/rcutorture/bin/functions.sh | 24 +++++++++++++++++++
.../selftests/rcutorture/bin/parse-console.sh | 7 ++++++
2 files changed, 31 insertions(+)
mode change 100644 => 100755 tools/testing/selftests/rcutorture/bin/functions.sh
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
old mode 100644
new mode 100755
index b8e2ea23cb3f..a5c74e508e41
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -331,3 +331,30 @@ specify_qemu_net () {
echo $1 -net none
fi
}
+
+# Extract the ftrace output from the console log output
+# The ftrace output in the original logs look like:
+# Dumping ftrace buffer:
+# ---------------------------------
+# [...]
+# ---------------------------------
+extract_ftrace_from_console() {
+ awk '
+ /Dumping ftrace buffer:/ {
+ buffer_count++
+ print "Ftrace dump " buffer_count ":"
+ capture = 1
+ next
+ }
+ /---------------------------------/ {
+ if(capture == 1) {
+ capture = 2
+ next
+ } else if(capture == 2) {
+ capture = 0
+ print ""
+ }
+ }
+ capture == 2
+ ' "$1";
+}
diff --git a/tools/testing/selftests/rcutorture/bin/parse-console.sh b/tools/testing/selftests/rcutorture/bin/parse-console.sh
index 9ab0f6bc172c..e3d2f69ec0fb 100755
--- a/tools/testing/selftests/rcutorture/bin/parse-console.sh
+++ b/tools/testing/selftests/rcutorture/bin/parse-console.sh
@@ -182,3 +182,10 @@ if ! test -s $file.diags
then
rm -f $file.diags
fi
+
+# Call extract_ftrace_from_console function, if the output is empty,
+# don't create $file.ftrace. Otherwise output the results to $file.ftrace
+extract_ftrace_from_console $file > $file.ftrace
+if [ ! -s $file.ftrace ]; then
+ rm -f $file.ftrace
+fi
--
2.41.0.694.ge786442a9b-goog
[ Upstream commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 ]
Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
ret = kstrtou8(buf, 10, &val);
if (ret)
return ret;
mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
static ssize_t config_num_requests_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int rc;
mutex_lock(&test_fw_mutex);
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
// NOTE: HERE is the race!!! Function can be preempted!
// test_fw_config->reqs can change between the release of
// the lock about and acquire of the lock in the
// test_dev_config_update_u8()
rc = test_dev_config_update_u8(buf, count,
&test_fw_config->num_requests);
out:
return rc;
}
static ssize_t config_read_fw_idx_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return test_dev_config_update_u8(buf, count,
&test_fw_config->read_fw_idx);
}
The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.
To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.
Having two locks wouldn't assure a race-proof mutual exclusion.
This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
int ret;
mutex_lock(&test_fw_mutex);
ret = __test_dev_config_update_u8(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
}
doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.
Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests")
Cc: Luis R. Rodriguez <mcgrof(a)kernel.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Russ Weight <russell.h.weight(a)intel.com>
Cc: Takashi Iwai <tiwai(a)suse.de>
Cc: Tianfei Zhang <tianfei.zhang(a)intel.com>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Colin Ian King <colin.i.king(a)gmail.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: linux-kselftest(a)vger.kernel.org
Cc: stable(a)vger.kernel.org # v5.4, 4.19, 4.14
Suggested-by: Dan Carpenter <error27(a)gmail.com>
Link: https://lore.kernel.org/r/20230509084746.48259-1-mirsad.todorovac@alu.unizg…
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr>
[ This is the patch to fix the racing condition in locking for the 5.4, ]
[ 4.19 and 4.14 stable branches. Not all the fixes from the upstream ]
[ commit apply, but those which do are verbatim equal to those in the ]
[ upstream commit. ]
---
v4:
verbatim the same patch as for the 5.4 stable tree which patchwork didn't apply
lib/test_firmware.c | 37 ++++++++++++++++++++++++++++---------
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 34210306ea66..d407e5e670f3 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -283,16 +283,26 @@ static ssize_t config_test_show_str(char *dst,
return len;
}
-static int test_dev_config_update_bool(const char *buf, size_t size,
- bool *cfg)
+static inline int __test_dev_config_update_bool(const char *buf, size_t size,
+ bool *cfg)
{
int ret;
- mutex_lock(&test_fw_mutex);
if (strtobool(buf, cfg) < 0)
ret = -EINVAL;
else
ret = size;
+
+ return ret;
+}
+
+static int test_dev_config_update_bool(const char *buf, size_t size,
+ bool *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_bool(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
@@ -322,7 +332,7 @@ static ssize_t test_dev_config_show_int(char *buf, int cfg)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
-static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+static inline int __test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
int ret;
long new;
@@ -334,14 +344,23 @@ static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
if (new > U8_MAX)
return -EINVAL;
- mutex_lock(&test_fw_mutex);
*(u8 *)cfg = new;
- mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
+static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_u8(buf, size, cfg);
+ mutex_unlock(&test_fw_mutex);
+
+ return ret;
+}
+
static ssize_t test_dev_config_show_u8(char *buf, u8 cfg)
{
u8 val;
@@ -374,10 +393,10 @@ static ssize_t config_num_requests_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_u8(buf, count,
- &test_fw_config->num_requests);
+ rc = __test_dev_config_update_u8(buf, count,
+ &test_fw_config->num_requests);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
--
2.34.1
Add new feature checks related to crypto to the hwcap test.
The following is a log snippet from my local testing environment
based on for-next/selftests:
~~~
TAP version 13
1..111
# AES present
ok 1 cpuinfo_match_AES
ok 2 sigill_AES
ok 3 # SKIP sigbus_AES
# CRC32 present
ok 4 cpuinfo_match_CRC32
ok 5 sigill_CRC32
ok 6 # SKIP sigbus_CRC32
ok 7 cpuinfo_match_CSSC
# sigill_reported for CSSC
ok 8 # SKIP sigill_CSSC
ok 9 # SKIP sigbus_CSSC
# FP present
ok 10 cpuinfo_match_FP
ok 11 sigill_FP
ok 12 # SKIP sigbus_FP
# JSCVT present
ok 13 cpuinfo_match_JSCVT
ok 14 sigill_JSCVT
ok 15 # SKIP sigbus_JSCVT
# LRCPC present
ok 16 cpuinfo_match_LRCPC
ok 17 sigill_LRCPC
ok 18 # SKIP sigbus_LRCPC
# LRCPC2 present
ok 19 cpuinfo_match_LRCPC2
ok 20 sigill_LRCPC2
ok 21 # SKIP sigbus_LRCPC2
# LSE present
ok 22 cpuinfo_match_LSE
ok 23 sigill_LSE
ok 24 # SKIP sigbus_LSE
# LSE2 present
ok 25 cpuinfo_match_LSE2
ok 26 sigill_LSE2
ok 27 sigbus_LSE2
ok 28 cpuinfo_match_MOPS
ok 29 sigill_MOPS
ok 30 # SKIP sigbus_MOPS
# RNG present
ok 31 cpuinfo_match_RNG
ok 32 sigill_RNG
ok 33 # SKIP sigbus_RNG
# PMULL present
ok 34 cpuinfo_match_PMULL
ok 35 sigill_PMULL
ok 36 # SKIP sigbus_PMULL
ok 37 cpuinfo_match_RPRFM
ok 38 # SKIP sigill_RPRFM
ok 39 # SKIP sigbus_RPRFM
# SHA1 present
ok 40 cpuinfo_match_SHA1
ok 41 sigill_SHA1
ok 42 # SKIP sigbus_SHA1
# SHA2 present
ok 43 cpuinfo_match_SHA2
ok 44 sigill_SHA2
ok 45 # SKIP sigbus_SHA2
# SHA512 present
ok 46 cpuinfo_match_SHA512
ok 47 sigill_SHA512
ok 48 # SKIP sigbus_SHA512
ok 49 cpuinfo_match_SME
ok 50 sigill_SME
ok 51 # SKIP sigbus_SME
ok 52 cpuinfo_match_SME2
ok 53 sigill_SME2
ok 54 # SKIP sigbus_SME2
ok 55 cpuinfo_match_SME 2.1
# sigill_reported for SME 2.1
ok 56 # SKIP sigill_SME 2.1
ok 57 # SKIP sigbus_SME 2.1
ok 58 cpuinfo_match_SME I16I32
# sigill_reported for SME I16I32
ok 59 # SKIP sigill_SME I16I32
ok 60 # SKIP sigbus_SME I16I32
ok 61 cpuinfo_match_SME BI32I32
# sigill_reported for SME BI32I32
ok 62 # SKIP sigill_SME BI32I32
ok 63 # SKIP sigbus_SME BI32I32
ok 64 cpuinfo_match_SME B16B16
# sigill_reported for SME B16B16
ok 65 # SKIP sigill_SME B16B16
ok 66 # SKIP sigbus_SME B16B16
ok 67 cpuinfo_match_SME F16F16
# sigill_reported for SME F16F16
ok 68 # SKIP sigill_SME F16F16
ok 69 # SKIP sigbus_SME F16F16
# SVE present
ok 70 cpuinfo_match_SVE
ok 71 sigill_SVE
ok 72 # SKIP sigbus_SVE
ok 73 cpuinfo_match_SVE 2
# sigill_reported for SVE 2
ok 74 # SKIP sigill_SVE 2
ok 75 # SKIP sigbus_SVE 2
ok 76 cpuinfo_match_SVE 2.1
# sigill_reported for SVE 2.1
ok 77 # SKIP sigill_SVE 2.1
ok 78 # SKIP sigbus_SVE 2.1
ok 79 cpuinfo_match_SVE AES
# sigill_reported for SVE AES
ok 80 # SKIP sigill_SVE AES
ok 81 # SKIP sigbus_SVE AES
ok 82 cpuinfo_match_SVE2 PMULL
# sigill_reported for SVE2 PMULL
ok 83 # SKIP sigill_SVE2 PMULL
ok 84 # SKIP sigbus_SVE2 PMULL
ok 85 cpuinfo_match_SVE2 BITPERM
# sigill_reported for SVE2 BITPERM
ok 86 # SKIP sigill_SVE2 BITPERM
ok 87 # SKIP sigbus_SVE2 BITPERM
ok 88 cpuinfo_match_SVE2 SHA3
# sigill_reported for SVE2 SHA3
ok 89 # SKIP sigill_SVE2 SHA3
ok 90 # SKIP sigbus_SVE2 SHA3
ok 91 cpuinfo_match_SVE2 SM4
# sigill_reported for SVE2 SM4
ok 92 # SKIP sigill_SVE2 SM4
ok 93 # SKIP sigbus_SVE2 SM4
# SVE2 I8MM present
ok 94 cpuinfo_match_SVE2 I8MM
ok 95 sigill_SVE2 I8MM
ok 96 # SKIP sigbus_SVE2 I8MM
# SVE2 F32MM present
ok 97 cpuinfo_match_SVE2 F32MM
ok 98 sigill_SVE2 F32MM
ok 99 # SKIP sigbus_SVE2 F32MM
# SVE2 F64MM present
ok 100 cpuinfo_match_SVE2 F64MM
ok 101 sigill_SVE2 F64MM
ok 102 # SKIP sigbus_SVE2 F64MM
# SVE2 BF16 present
ok 103 cpuinfo_match_SVE2 BF16
ok 104 sigill_SVE2 BF16
ok 105 # SKIP sigbus_SVE2 BF16
ok 106 cpuinfo_match_SVE2 EBF16
ok 107 # SKIP sigill_SVE2 EBF16
ok 108 # SKIP sigbus_SVE2 EBF16
ok 109 cpuinfo_match_HBC
ok 110 sigill_HBC
ok 111 # SKIP sigbus_HBC
# Totals: pass:60 fail:0 xfail:0 xpass:0 skip:51 error:0
~~~
Zeng Heng (4):
kselftest/arm64: add SHA1 and related features to hwcap test
kselftest/arm64: add AES feature check to hwcap test
kselftest/arm64: add pmull feature to hwcap test
kselftest/arm64: add jscvt feature to hwcap test
tools/testing/selftests/arm64/abi/hwcap.c | 77 +++++++++++++++++++++++
1 file changed, 77 insertions(+)
--
2.25.1
Observed occassional failures in the futex_wait_timeout test:
ok 1 futex_wait relative succeeds
ok 2 futex_wait_bitset realtime succeeds
ok 3 futex_wait_bitset monotonic succeeds
ok 4 futex_wait_requeue_pi realtime succeeds
ok 5 futex_wait_requeue_pi monotonic succeeds
not ok 6 futex_lock_pi realtime returned 0
......
The test expects the child thread to complete some steps before
the parent thread gets to run. There is an implicit expectation
of the order of invocation of futex_lock_pi between the child thread
and the parent thread. Make this order explicit. If the order is
not met, the futex_lock_pi call in the parent thread succeeds and
will not timeout.
Fixes: f4addd54b161 ("selftests: futex: Expand timeout test")
Signed-off-by: Nysal Jan K.A <nysal(a)linux.ibm.com>
---
.../selftests/futex/functional/futex_wait_timeout.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/futex/functional/futex_wait_timeout.c b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
index 3651ce17beeb..d183f878360b 100644
--- a/tools/testing/selftests/futex/functional/futex_wait_timeout.c
+++ b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
@@ -24,6 +24,7 @@
static long timeout_ns = 100000; /* 100us default timeout */
static futex_t futex_pi;
+static pthread_barrier_t barrier;
void usage(char *prog)
{
@@ -48,6 +49,8 @@ void *get_pi_lock(void *arg)
if (ret != 0)
error("futex_lock_pi failed\n", ret);
+ pthread_barrier_wait(&barrier);
+
/* Blocks forever */
ret = futex_wait(&lock, 0, NULL, 0);
error("futex_wait failed\n", ret);
@@ -130,6 +133,7 @@ int main(int argc, char *argv[])
basename(argv[0]));
ksft_print_msg("\tArguments: timeout=%ldns\n", timeout_ns);
+ pthread_barrier_init(&barrier, NULL, 2);
pthread_create(&thread, NULL, get_pi_lock, NULL);
/* initialize relative timeout */
@@ -163,6 +167,9 @@ int main(int argc, char *argv[])
res = futex_wait_requeue_pi(&f1, f1, &futex_pi, &to, 0);
test_timeout(res, &ret, "futex_wait_requeue_pi monotonic", ETIMEDOUT);
+ /* Wait until the other thread calls futex_lock_pi() */
+ pthread_barrier_wait(&barrier);
+ pthread_barrier_destroy(&barrier);
/*
* FUTEX_LOCK_PI with CLOCK_REALTIME
* Due to historical reasons, FUTEX_LOCK_PI supports only realtime
--
2.41.0
The user_events selftests were removed from the standard set of
selftests due to the uapi header it relies on having been temporarily
removed. That header is now reinstated so we can reenable the tests.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/user_events/Makefile | 8 --------
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 666b56f22a41..4e221bb620b4 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -89,6 +89,7 @@ TARGETS += tmpfs
TARGETS += tpm2
TARGETS += tty
TARGETS += user
+TARGETS += user_events
TARGETS += vDSO
TARGETS += mm
TARGETS += x86
diff --git a/tools/testing/selftests/user_events/Makefile b/tools/testing/selftests/user_events/Makefile
index 9e95bd41b0b4..10fcd0066203 100644
--- a/tools/testing/selftests/user_events/Makefile
+++ b/tools/testing/selftests/user_events/Makefile
@@ -2,14 +2,6 @@
CFLAGS += -Wl,-no-as-needed -Wall $(KHDR_INCLUDES)
LDLIBS += -lrt -lpthread -lm
-# Note:
-# This test depends on <linux/user_events.h> exported in uapi
-# The following commit removed user_events.h out of uapi:
-# commit 5cfff569cab8bf544bab62c911c5d6efd5af5e05
-# tracing: Move user_events.h temporarily out of include/uapi
-# This test will not compile until user_events.h is added
-# back to uapi.
-
TEST_GEN_PROGS = ftrace_test dyn_test perf_test abi_test
TEST_FILES := settings
---
base-commit: 5d0c230f1de8c7515b6567d9afba1f196fb4e2f4
change-id: 20230805-kselftest-user-events-e4beff821b0f
Best regards,
--
Mark Brown <broonie(a)kernel.org>
We have some dmabuf-heaps and perf_events tests but they are not hooked
up to the kselftest build infrastructure which is a bit of an obstacle
to running them in systems with generic infrastructure for selftests.
Add them to the top level kselftest Makefile so they get built as
standard.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 666b56f22a41..bdee501596ef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -12,6 +12,7 @@ TARGETS += core
TARGETS += cpufreq
TARGETS += cpu-hotplug
TARGETS += damon
+TARGETS += dmabuf-heaps
TARGETS += drivers/dma-buf
TARGETS += drivers/s390x/uvdevice
TARGETS += drivers/net/bonding
@@ -56,6 +57,7 @@ TARGETS += net/mptcp
TARGETS += net/openvswitch
TARGETS += netfilter
TARGETS += nsfs
+TARGETS += perf_events
TARGETS += pidfd
TARGETS += pid_namespace
TARGETS += powerpc
@@ -88,6 +90,7 @@ endif
TARGETS += tmpfs
TARGETS += tpm2
TARGETS += tty
+TARGETS += uevents
TARGETS += user
TARGETS += vDSO
TARGETS += mm
---
base-commit: 5d0c230f1de8c7515b6567d9afba1f196fb4e2f4
change-id: 20230805-kselftest-perf-events-build-c0e0f1182bae
Best regards,
--
Mark Brown <broonie(a)kernel.org>