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

[PATCH 0/2] [RESEND] Fold checksum at the end of bpf_csum_diff and fix

by Paolo Pisati

From: Paolo Pisati <paolo.pisati(a)canonical.com> After applying patch 0001, all checksum implementations i could test (x86-64, arm64 and arm), now agree on the return value. Patch 0002 fix the expected return value for test #13: i did the calculation manually, and it correspond. Unfortunately, after applying patch 0001, other test cases now fail in test_verifier: $ sudo ./tools/testing/selftests/bpf/test_verifier ... #417/p helper access to variable memory: size = 0 allowed on NULL (ARG_PTR_TO_MEM_OR_NULL) FAIL retval 65535 != 0 #419/p helper access to variable memory: size = 0 allowed on != NULL stack pointer (ARG_PTR_TO_MEM_OR_NULL) FAIL retval 65535 != 0 #423/p helper access to variable memory: size possible = 0 allowed on != NULL packet pointer (ARG_PTR_TO_MEM_OR_NULL) FAIL retval 65535 != 0 ... Summary: 1500 PASSED, 0 SKIPPED, 3 FAILED And there are probably other fallouts in other selftests - someone familiar should take a look before applying these patches. Paolo Pisati (2): bpf: bpf_csum_diff: fold the checksum before returning the value bpf, selftest: fix checksum value for test #13 net/core/filter.c | 2 +- tools/testing/selftests/bpf/verifier/array_access.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.17.1

5 years, 11 months

2
3
0 0

[PATCH] vsyscall: use __iter_div_u64_rem()

by Arnd Bergmann

On 32-bit x86 when building with clang-9, the loop gets turned back into an inefficient division that causes a link error: kernel/time/vsyscall.o: In function `update_vsyscall': vsyscall.c:(.text+0xe3): undefined reference to `__udivdi3' Use the provided __iter_div_u64_rem() function that is meant to address the same case in other files. Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- kernel/time/vsyscall.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c index a80893180826..8cf3596a4ce6 100644 --- a/kernel/time/vsyscall.c +++ b/kernel/time/vsyscall.c @@ -104,11 +104,7 @@ void update_vsyscall(struct timekeeper *tk) vdso_ts->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift; nsec = nsec + tk->wall_to_monotonic.tv_nsec; - while (nsec >= NSEC_PER_SEC) { - nsec = nsec - NSEC_PER_SEC; - vdso_ts->sec++; - } - vdso_ts->nsec = nsec; + vdso_ts->sec += __iter_div_u64_rem(nsec, NSEC_PER_SEC, &vdso_ts->nsec); if (__arch_use_vsyscall(vdata)) update_vdso_data(vdata, tk); -- 2.20.0

5 years, 11 months

4
6
0 0

[PATCH] selftests: breakpoints: Fix compile error with arun_test()

by Nobuhiro Iwamatsu

By undefined run_test(), compile of breakpoint_test_arm64.c fails. This changes arun_test to run_test. ---- reakpoint_test_arm64.c: In function 'main': breakpoint_test_arm64.c:217:14: warning: implicit declaration of function 'run_test'; did you mean 'arun_test'? [-Wimplicit-function-declaration] result = run_test(size, MIN(size, 8), wr, wp); ^~~~~~~~ arun_test ---- Fixes: 5821ba969511 ("selftests: Add test plan API to kselftest.h and adjust callers") Signed-off-by: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> --- tools/testing/selftests/breakpoints/breakpoint_test_arm64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c index 58ed5eeab709..ad41ea69001b 100644 --- a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c +++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c @@ -109,7 +109,7 @@ static bool set_watchpoint(pid_t pid, int size, int wp) return false; } -static bool arun_test(int wr_size, int wp_size, int wr, int wp) +static bool run_test(int wr_size, int wp_size, int wr, int wp) { int status; siginfo_t siginfo; -- 2.20.1

5 years, 11 months

1
0
0 0

[PATCH v7 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

by Brendan Higgins

## TL;DR This is a pretty straightforward follow-up to Luis' comments on PATCH v6: There is nothing that changes any functionality or usage. As for our current status, we only need reviews/acks on the following patches: - [PATCH v7 06/18] kbuild: enable building KUnit - Need a review or ack from Masahiro Yamada or Michal Marek - [PATCH v7 08/18] objtool: add kunit_try_catch_throw to the noreturn list - Need a review or ack from Josh Poimboeuf or Peter Zijlstra Other than that, I think we should be good to go. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.2/v7 branch. ## Changes Since Last Version Aside from renaming `struct kunit_module` to `struct kunit_suite`, there isn't really anything in here that changes any functionality: - Rebased on v5.2 - Added Iurii as a maintainer for PROC SYSCTL, as suggested by Luis. - Removed some references to spinlock that I failed to remove in the previous version, as pointed out by Luis. - Cleaned up some comments, as suggested by Luis. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.2/v7 -- 2.22.0.410.gd8fdbe21b5-goog

5 years, 11 months

4
24
0 0

[PATCH v8 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

by Brendan Higgins

## TL;DR This new patch set only contains a very minor change suggested by Masahiro to [PATCH v7 06/18] and is otherwise identical to PATCH v7. Also, with Josh's ack on the preceding patch set, I think we now have all necessary reviews and acks from all interested parties. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.2/v8 branch. ## Changes Since Last Version Like I said in the TL;DR, there is only one minor change since the previous revision. That change only affects patch 06/18; it makes it so that make doesn't attempt to scan the kunit/ directory when CONFIG_KUNIT is not set as suggested by Masahiro. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.2/v8 -- 2.22.0.410.gd8fdbe21b5-goog

5 years, 11 months

2
19
0 0

Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section

by Iurii Zaikin

> On Mon, Jul 8, 2019 at 4:16 PM Brendan Higgins <brendanhiggins(a)google.com> wrote: >> >> CC'ing Iurii Zaikin >> >> On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof(a)kernel.org> wrote: >> > >> > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote: >> > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section. >> > > >> > > Signed-off-by: Brendan Higgins <brendanhiggins(a)google.com> >> > > Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> >> > > Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> >> > > Acked-by: Luis Chamberlain <mcgrof(a)kernel.org> >> > >> > Come to think of it, I'd welcome Iurii to be added as a maintainer, >> > with the hope Iurii would be up to review only the kunit changes. Of >> > course if Iurii would be up to also help review future proc changes, >> > even better. 3 pair of eyeballs is better than 2 pairs. >> >> What do you think, Iurii? I'm in.

5 years, 11 months

1
0
0 0

[PATCH v6 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

by Brendan Higgins

## TL;DR This is a pretty straightforward follow-up to Stephen and Luis' comments on PATCH v5: There is nothing that really changes any functionality or usage with the minor exception that I renamed `struct kunit_module` to `struct kunit_suite`. Nevertheless, a good deal of clean ups and fixes. See "Changes Since Last Version" section below. As for our current status, right now we got Reviewed-bys on all patches except: - [PATCH v6 08/18] objtool: add kunit_try_catch_throw to the noreturn list However, it would probably be good to get reviews/acks from the subsystem maintainers on: - [PATCH v6 06/18] kbuild: enable building KUnit - [PATCH v6 08/18] objtool: add kunit_try_catch_throw to the noreturn list - [PATCH v6 15/18] Documentation: kunit: add documentation for KUnit - [PATCH v6 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() Other than that, I think we should be good to go. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.2-rc7/v6 branch. ## Changes Since Last Version Aside from renaming `struct kunit_module` to `struct kunit_suite`, there isn't really anything in here that changes any functionality: - Rebased on v5.2-rc7 - Got rid of spinlocks. - Now update success field using WRITE_ONCE. - Suggested by Stephen - Other instances replaced by mutex. - Suggested by Stephen and Luis - Renamed `struct kunit_module` to `struct kunit_suite`. - Inspired by Luis. - Fixed a broken example of how to use kunit_tool. - Pointed out by Ted - Added descriptions to unit tests. - Suggested by Luis - Labeled unit tests which tested the API. - Suggested by Luis - Made a number of minor cleanups. - Suggested by Luis and Stephen. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.2-rc7/v6 -- 2.22.0.410.gd8fdbe21b5-goog

5 years, 11 months

2
27
0 0

[PATCH] selftests/ftrace: avoid failure when trying to probe a notrace function

by Thadeu Lima de Souza Cascardo

Check that the function is on available_filter_functions. If it's not, mark the test as unresolved, instead of failing it. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> --- tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc index 3fb70e01b1fe..e4dff034da12 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc @@ -26,6 +26,7 @@ test -d events/kprobes2/event2 || exit_failure FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "` [ "x" != "x$FUNC" ] || exit_unresolved +grep -n "$FUNC" available_filter_functions || exit_unresolved echo "p $FUNC" > kprobe_events EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` [ "x" != "x$EVENT" ] || exit_failure -- 2.20.1

5 years, 11 months

2
2
0 0

[PATCH for 5.2] rseq/selftests: Fix Thumb mode build failure on arm32

by Mathieu Desnoyers

Using ".arm .inst" for the arm signature introduces build issues for programs compiled in Thumb mode because the assembler stays in the arm mode for the rest of the inline assembly. Revert to using a ".word" to express the signature as data instead. The choice of signature is a valid trap instruction on arm32 little endian, where both code and data are little endian. ARMv6+ big endian (BE8) generates mixed endianness code vs data: little-endian code and big-endian data. The data value of the signature needs to have its byte order reversed to generate the trap instruction. Prior to ARMv6, -mbig-endian generates big-endian code and data (which match), so the endianness of the data representation of the signature should not be reversed. However, the choice between BE32 and BE8 is done by the linker, so we cannot know whether code and data endianness will be mixed before the linker is invoked. So rather than try to play tricks with the linker, the rseq signature is simply data (not a trap instruction) prior to ARMv6 on big endian. This is why the signature is expressed as data (.word) rather than as instruction (.inst) in assembler. Because a ".word" is used to emit the signature, it will be interpreted as a literal pool by a disassembler, not as an actual instruction. Considering that the signature is not meant to be executed except in scenarios where the program execution is completely bogus, this should not be an issue. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Acked-by: Will Deacon <will.deacon(a)arm.com> CC: Peter Zijlstra <peterz(a)infradead.org> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Joel Fernandes <joelaf(a)google.com> CC: Catalin Marinas <catalin.marinas(a)arm.com> CC: Dave Watson <davejwatson(a)fb.com> CC: Will Deacon <will.deacon(a)arm.com> CC: Shuah Khan <shuah(a)kernel.org> CC: Andi Kleen <andi(a)firstfloor.org> CC: linux-kselftest(a)vger.kernel.org CC: "H . Peter Anvin" <hpa(a)zytor.com> CC: Chris Lameter <cl(a)linux.com> CC: Russell King <linux(a)arm.linux.org.uk> CC: Michael Kerrisk <mtk.manpages(a)gmail.com> CC: "Paul E . McKenney" <paulmck(a)linux.vnet.ibm.com> CC: Paul Turner <pjt(a)google.com> CC: Boqun Feng <boqun.feng(a)gmail.com> CC: Josh Triplett <josh(a)joshtriplett.org> CC: Steven Rostedt <rostedt(a)goodmis.org> CC: Ben Maurer <bmaurer(a)fb.com> CC: linux-api(a)vger.kernel.org CC: Andy Lutomirski <luto(a)amacapital.net> CC: Andrew Morton <akpm(a)linux-foundation.org> CC: Linus Torvalds <torvalds(a)linux-foundation.org> CC: Carlos O'Donell <carlos(a)redhat.com> CC: Florian Weimer <fweimer(a)redhat.com> --- tools/testing/selftests/rseq/rseq-arm.h | 61 ++++++++++++++++++--------------- 1 file changed, 33 insertions(+), 28 deletions(-) diff --git a/tools/testing/selftests/rseq/rseq-arm.h b/tools/testing/selftests/rseq/rseq-arm.h index 84f28f147fb6..5943c816c07c 100644 --- a/tools/testing/selftests/rseq/rseq-arm.h +++ b/tools/testing/selftests/rseq/rseq-arm.h @@ -6,6 +6,8 @@ */ /* + * - ARM little endian + * * RSEQ_SIG uses the udf A32 instruction with an uncommon immediate operand * value 0x5de3. This traps if user-space reaches this instruction by mistake, * and the uncommon operand ensures the kernel does not move the instruction @@ -22,36 +24,40 @@ * def3 udf #243 ; 0xf3 * e7f5 b.n <7f5> * - * pre-ARMv6 big endian code: - * e7f5 b.n <7f5> - * def3 udf #243 ; 0xf3 + * - ARMv6+ big endian (BE8): * * ARMv6+ -mbig-endian generates mixed endianness code vs data: little-endian - * code and big-endian data. Ensure the RSEQ_SIG data signature matches code - * endianness. Prior to ARMv6, -mbig-endian generates big-endian code and data - * (which match), so there is no need to reverse the endianness of the data - * representation of the signature. However, the choice between BE32 and BE8 - * is done by the linker, so we cannot know whether code and data endianness - * will be mixed before the linker is invoked. + * code and big-endian data. The data value of the signature needs to have its + * byte order reversed to generate the trap instruction: + * + * Data: 0xf3def5e7 + * + * Translates to this A32 instruction pattern: + * + * e7f5def3 udf #24035 ; 0x5de3 + * + * Translates to this T16 instruction pattern: + * + * def3 udf #243 ; 0xf3 + * e7f5 b.n <7f5> + * + * - Prior to ARMv6 big endian (BE32): + * + * Prior to ARMv6, -mbig-endian generates big-endian code and data + * (which match), so the endianness of the data representation of the + * signature should not be reversed. However, the choice between BE32 + * and BE8 is done by the linker, so we cannot know whether code and + * data endianness will be mixed before the linker is invoked. So rather + * than try to play tricks with the linker, the rseq signature is simply + * data (not a trap instruction) prior to ARMv6 on big endian. This is + * why the signature is expressed as data (.word) rather than as + * instruction (.inst) in assembler. */ -#define RSEQ_SIG_CODE 0xe7f5def3 - -#ifndef __ASSEMBLER__ - -#define RSEQ_SIG_DATA \ - ({ \ - int sig; \ - asm volatile ("b 2f\n\t" \ - "1: .inst " __rseq_str(RSEQ_SIG_CODE) "\n\t" \ - "2:\n\t" \ - "ldr %[sig], 1b\n\t" \ - : [sig] "=r" (sig)); \ - sig; \ - }) - -#define RSEQ_SIG RSEQ_SIG_DATA - +#ifdef __ARMEB__ +#define RSEQ_SIG 0xf3def5e7 /* udf #24035 ; 0x5de3 (ARMv6+) */ +#else +#define RSEQ_SIG 0xe7f5def3 /* udf #24035 ; 0x5de3 */ #endif #define rseq_smp_mb() __asm__ __volatile__ ("dmb" ::: "memory", "cc") @@ -125,8 +131,7 @@ do { \ __rseq_str(table_label) ":\n\t" \ ".word " __rseq_str(version) ", " __rseq_str(flags) "\n\t" \ ".word " __rseq_str(start_ip) ", 0x0, " __rseq_str(post_commit_offset) ", 0x0, " __rseq_str(abort_ip) ", 0x0\n\t" \ - ".arm\n\t" \ - ".inst " __rseq_str(RSEQ_SIG_CODE) "\n\t" \ + ".word " __rseq_str(RSEQ_SIG) "\n\t" \ __rseq_str(label) ":\n\t" \ teardown \ "b %l[" __rseq_str(abort_label) "]\n\t" -- 2.11.0

5 years, 11 months

2
2
0 0

[PATCH] selftests/powerpc: Add missing newline at end of file

by Geert Uytterhoeven

"git diff" says: \ No newline at end of file after modifying the file. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- tools/testing/selftests/powerpc/mm/.gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/mm/.gitignore b/tools/testing/selftests/powerpc/mm/.gitignore index ba919308fe3052f3..16861ab840f57e90 100644 --- a/tools/testing/selftests/powerpc/mm/.gitignore +++ b/tools/testing/selftests/powerpc/mm/.gitignore @@ -3,4 +3,4 @@ subpage_prot tempfile prot_sao segv_errors -wild_bctr \ No newline at end of file +wild_bctr -- 2.17.1

5 years, 12 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror