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

[PATCH v2 0/2] selftests/x86: AMX-related test improvements

by Chang S. Bae

Sorry for the delay in this update. Changes from v1: * Improve the skip message along with the changelog massage (Suah Khan). * Simplify the feature support check (Suah Khan). === Cover Letter === A couple of test updates are included: * With the STRICT_SIGALTSTACK_SIZE option [1,2], the kernel's altstack check becomes stringent. The x86 sigaltstack test is ignorant about this. Adjust the test now. This check was established [3] to ensure every AMX task's altstack is sufficient (regardless of that option) [4]. * The AMX test wrongly fails on non-AMX machines. Fix the code to skip the test instead. The series is available in this repository: git://github.com/intel/amx-linux.git selftest [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… [3] 3aac3ebea08f ("x86/signal: Implement sigaltstack size validation") [4] 4b7ca609a33d ("x86/signal: Use fpu::__state_user_size for sigalt stack validation") Chang S. Bae (2): selftests/x86/signal: Adjust the test to the kernel's altstack check selftests/x86/amx: Fix the test to avoid failure when AMX is unavailable tools/testing/selftests/x86/amx.c | 31 ++++++++--------------- tools/testing/selftests/x86/sigaltstack.c | 14 +++++++++- 2 files changed, 23 insertions(+), 22 deletions(-) base-commit: 32346491ddf24599decca06190ebca03ff9de7f8 -- 2.17.1

2 years, 3 months

1
6
0 0

[BUG] selftests/firmware: copious kernel memory leaks in test_fw_run_batch_request()

by Mirsad Todorovac

Hi all, Platform is AlmaLinux 8.7 (CentOS fork), Lenovo desktop LENOVO_MT_10TX_BU_Lenovo_FM_V530S-07ICB with the BIOS M22KT49A dated 11/10/2022. Running Torvalds vanilla kernel 6.3-rc3 commit 6981739a967c with CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUG_{KOBJECT,KOBJECT_RELEASE} enabled. The leak is cummulative, it can be reproduced with tools/testing/selftests/firmware/*.sh scripts. The leaks are in chunks of 1024 bytes (+ overhead), but so far I could not reproduce w/o root privileges, as tests refuse to run as unprivileged user. (This is not the proof of non-existence of an unprivileged automated exploit that would exhaust the kernel memory at approx. rate 4 MB/hour on our setup. This would mean about 96 MB / day or 3 GB / month (of kernel memory). TEST RESULTS (showing the number of kmemleaks per test): root@pc-mtodorov marvin]# grep -c 'comm "test_' linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw*.log linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw_fallback.sh.log:0 linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw_filesystem.sh.log:60 linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw_lib.sh.log:9 linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw_run_tests.sh.log:196 linux/kernel_bugs/memleaks-6.3-rc3/kmemleak-fw_upload.sh.log:0 [root@pc-mtodorov marvin]# Leaks look like this: unreferenced object 0xffff943c390f8400 (size 1024): comm "test_firmware-0", pid 449178, jiffies 4381453603 (age 824.844s) hex dump (first 32 bytes): 45 46 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 EFGH4567........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff90aed68c>] slab_post_alloc_hook+0x8c/0x3e0 [<ffffffff90af4f69>] __kmem_cache_alloc_node+0x1d9/0x2a0 [<ffffffff90a6a6ae>] kmalloc_trace+0x2e/0xc0 [<ffffffff90eb2350>] test_fw_run_batch_request+0x90/0x170 [<ffffffff907d6dcf>] kthread+0x10f/0x140 [<ffffffff90602fa9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff943a902f6400 (size 1024): comm "test_firmware-1", pid 449179, jiffies 4381453603 (age 824.844s) hex dump (first 32 bytes): 45 46 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 EFGH4567........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff90aed68c>] slab_post_alloc_hook+0x8c/0x3e0 [<ffffffff90af4f69>] __kmem_cache_alloc_node+0x1d9/0x2a0 [<ffffffff90a6a6ae>] kmalloc_trace+0x2e/0xc0 [<ffffffff90eb2350>] test_fw_run_batch_request+0x90/0x170 [<ffffffff907d6dcf>] kthread+0x10f/0x140 [<ffffffff90602fa9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff943a902f0400 (size 1024): comm "test_firmware-2", pid 449180, jiffies 4381453603 (age 824.844s) hex dump (first 32 bytes): 45 46 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 EFGH4567........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff90aed68c>] slab_post_alloc_hook+0x8c/0x3e0 [<ffffffff90af4f69>] __kmem_cache_alloc_node+0x1d9/0x2a0 [<ffffffff90a6a6ae>] kmalloc_trace+0x2e/0xc0 [<ffffffff90eb2350>] test_fw_run_batch_request+0x90/0x170 [<ffffffff907d6dcf>] kthread+0x10f/0x140 [<ffffffff90602fa9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff943a902f4000 (size 1024): comm "test_firmware-3", pid 449181, jiffies 4381453603 (age 824.844s) hex dump (first 32 bytes): 45 46 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 EFGH4567........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff90aed68c>] slab_post_alloc_hook+0x8c/0x3e0 [<ffffffff90af4f69>] __kmem_cache_alloc_node+0x1d9/0x2a0 [<ffffffff90a6a6ae>] kmalloc_trace+0x2e/0xc0 [<ffffffff90eb2350>] test_fw_run_batch_request+0x90/0x170 [<ffffffff907d6dcf>] kthread+0x10f/0x140 [<ffffffff90602fa9>] ret_from_fork+0x29/0x50 Please find the build config, lshw output and the output of /sys/kernel/debug/kmemleak in the following directory: https://domac.alu.hr/~mtodorov/linux/bugreports/kmemleak-firmware/ NOTE: sent to the maintainers listed for selftest/firmware and those listed for lib/test_firmware.c . Best regards, Mirsad -- Mirsad Goran Todorovac Sistem inženjer Grafički fakultet | Akademija likovnih umjetnosti Sveučilište u Zagrebu System engineer Faculty of Graphic Arts | Academy of Fine Arts University of Zagreb, Republic of Croatia

2 years, 3 months

4
10
0 0

[PATCH v2 0/3] KVM: selftests: Fixes for broken tests

by Ryan Roberts

Hi Oliver, Here is a respin of the KVM selftests fixes, with your nits addressed; I've fixed the footer whitespace issue and I'm now using FIELD_GET() in the place where you suggested and a couple of other places too. I've also included the 3rd patch in this series (the ttbr0_el1 fix), which I originally sent separately - this is now using FIELD_GET() too. So this series superceeds [1] and [2]. Thanks, Ryan [1] https://lore.kernel.org/kvmarm/e8ed178a-0c67-3e00-a085-1d88fb3cb41f@arm.com/ [2] https://lore.kernel.org/kvmarm/20230302152033.242073-1-ryan.roberts@arm.com/ Ryan Roberts (3): KVM: selftests: Fixup config fragment for access_tracking_perf_test KVM: selftests: arm64: Fix pte encode/decode for PA bits > 48 KVM: selftests: arm64: Fix ttbr0_el1 encoding for PA bits > 48 tools/testing/selftests/kvm/config | 1 + .../selftests/kvm/lib/aarch64/processor.c | 39 ++++++++++++++----- 2 files changed, 30 insertions(+), 10 deletions(-) -- 2.25.1

2 years, 3 months

4
9
0 0

[PATCH] KVM: selftests: Comment newly defined aarch64 ID registers

by Mark Brown

All otherwise unspecified aarch64 ID registers should be read as zero so we cover the whole ID register space in the get-reg-list test but we've added comments for those that have been named. Add comments for ID_AA64PFR2_EL1, ID_AA64SMFR0_EL1, ID_AA64ISAR2_EL1, ID_AA64MMFR3_EL1 and ID_AA64MMFR4_EL1 which have been defined since the comments were added so someone looking for them will see that they are covered. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/kvm/aarch64/get-reg-list.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c index d287dd2cac0a..df8a8afca4fc 100644 --- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c +++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c @@ -807,10 +807,10 @@ static __u64 base_regs[] = { ARM64_SYS_REG(3, 0, 0, 3, 7), ARM64_SYS_REG(3, 0, 0, 4, 0), /* ID_AA64PFR0_EL1 */ ARM64_SYS_REG(3, 0, 0, 4, 1), /* ID_AA64PFR1_EL1 */ - ARM64_SYS_REG(3, 0, 0, 4, 2), + ARM64_SYS_REG(3, 0, 0, 4, 2), /* ID_AA64PFR2_EL1 */ ARM64_SYS_REG(3, 0, 0, 4, 3), ARM64_SYS_REG(3, 0, 0, 4, 4), /* ID_AA64ZFR0_EL1 */ - ARM64_SYS_REG(3, 0, 0, 4, 5), + ARM64_SYS_REG(3, 0, 0, 4, 5), /* ID_AA64SMFR0_EL1 */ ARM64_SYS_REG(3, 0, 0, 4, 6), ARM64_SYS_REG(3, 0, 0, 4, 7), ARM64_SYS_REG(3, 0, 0, 5, 0), /* ID_AA64DFR0_EL1 */ @@ -823,7 +823,7 @@ static __u64 base_regs[] = { ARM64_SYS_REG(3, 0, 0, 5, 7), ARM64_SYS_REG(3, 0, 0, 6, 0), /* ID_AA64ISAR0_EL1 */ ARM64_SYS_REG(3, 0, 0, 6, 1), /* ID_AA64ISAR1_EL1 */ - ARM64_SYS_REG(3, 0, 0, 6, 2), + ARM64_SYS_REG(3, 0, 0, 6, 2), /* ID_AA64ISAR2_EL1 */ ARM64_SYS_REG(3, 0, 0, 6, 3), ARM64_SYS_REG(3, 0, 0, 6, 4), ARM64_SYS_REG(3, 0, 0, 6, 5), @@ -832,8 +832,8 @@ static __u64 base_regs[] = { ARM64_SYS_REG(3, 0, 0, 7, 0), /* ID_AA64MMFR0_EL1 */ ARM64_SYS_REG(3, 0, 0, 7, 1), /* ID_AA64MMFR1_EL1 */ ARM64_SYS_REG(3, 0, 0, 7, 2), /* ID_AA64MMFR2_EL1 */ - ARM64_SYS_REG(3, 0, 0, 7, 3), - ARM64_SYS_REG(3, 0, 0, 7, 4), + ARM64_SYS_REG(3, 0, 0, 7, 3), /* ID_AA64MMFR3_EL1 */ + ARM64_SYS_REG(3, 0, 0, 7, 4), /* ID_AA64MMFR4_EL1 */ ARM64_SYS_REG(3, 0, 0, 7, 5), ARM64_SYS_REG(3, 0, 0, 7, 6), ARM64_SYS_REG(3, 0, 0, 7, 7), --- base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6 change-id: 20230210-kvm-arm64-getreg-comments-078093666fd5 Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 3 months

2
1
0 0

[PATCH] .gitignore: Exclude KUnit config dot-files

by Javier Martinez Canillas

There's a rule to ignore all the dot-files (.*) but we want to exclude the config files used by KUnit (.kunitconfig) since those are usually added to allow executing test suites without having to enable custom config symbols. Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 70ec6037fa7a..7f86e0837909 100644 --- a/.gitignore +++ b/.gitignore @@ -103,6 +103,7 @@ modules.order !.get_maintainer.ignore !.gitattributes !.gitignore +!.kunitconfig !.mailmap !.rustfmt.toml base-commit: ffe78bbd512166e0ef1cc4858010b128c510ed7d -- 2.40.0

2 years, 3 months

3
3
0 0

[PATCH v6 0/7] Support ROHM BU27034 ALS sensor

by Matti Vaittinen

Support ROHM BU27034 ALS sensor This series adds support for ROHM BU27034 Ambient Light Sensor. The BU27034 has configurable gain and measurement (integration) time settings. Both of these have inversely proportional relation to the sensor's intensity channel scale. Many users only set the scale, which means that many drivers attempt to 'guess' the best gain+time combination to meet the scale. Usually this is the biggest integration time which allows setting the requested scale. Typically, increasing the integration time has better accuracy than increasing the gain, which often amplifies the noise as well as the real signal. However, there may be cases where more responsive sensors are needed. So, in some cases the longest integration times may not be what the user prefers. The driver has no way of knowing this. Hence, the approach taken by this series is to allow user to set both the scale and the integration time with following logic: 1. When scale is set, the existing integration time is tried to be maintained as a first priority. 1a) If the requested scale can't be met by current time, then also other time + gain combinations are searched. If scale can be met by some other integration time, then the new time may be applied. If the time setting is common for all channels, then also other channels must be able to maintain their scale with this new time (by changing their gain). The new times are scanned in the order of preference (typically the longest times first). 1b) If the requested scale can be met using current time, then only the gain for the channel is changed. 2. When the integration time change - scale is tried to be maintained. When integration time change is requested also gain for all impacted channels is adjusted so that the scale is not changed, or is chaned as little as possible. This is different from the RFCv1 where the request was rejected if suitable gain couldn't be found for some channel(s). This logic is simple. When total gain (either caused by time or hw-gain) is doubled, the scale gets halved. Also, the supported times are given a 'multiplier' value which tells how much they increase the total gain. However, when I wrote this logic in bu27034 driver, I made quite a few errors on the way - and driver got pretty big. As I am writing drivers for two other sensors (RGB C/IR + flicker BU27010 and RGB C/IR BU27008) with similar gain-time-scale logic I thought that adding common helpers for these computations might be wise. I hope this way all the bugs will be concentrated in one place and not in every individual driver ;) Hence, this series also intriduces IIO gain-time-scale helpers (abbreviated as gts-helpers) + a couple of KUnit tests for the most hairy parts. Speaking of which - testing the devm interfaces requires a 'dummy device'. I've learned that there has been at least two ways of handling this kind of a dependecy. 1) Using a root_device_[un]register() functions (with or without a wrapper) 2) Using dummy platform_device. Way 2) is seen as abusing platform_devices to something they should not be used. Way 1) is also seen sub-optimal - and after a discussion a 'kunit dummy device' is being worked on by David Gow: https://lore.kernel.org/linux-kselftest/20230325043104.3761770-1-davidgow@g… David's work relies on not yet in-tree kunit deferring API. Schedule for this work is - as always in case of upstream development - unkonwn. In order to be self-contained while still easily 'fixable when David's work is completed' this series introduces warappers named similar to what was suggested by david - and which are intended to have similar behaviour (automatic clean-up upon test completion). These wrappers do still use root-device APIs underneath but this should be fixed by David's work. Finally, these added helpers do provide some value also for drivers which only: a) allow gain change or b) allow changing both the time and gain while trying to maintain the scale. For a) we provide the gain - selector (register value) table format + selector to gain look-ups, gain <-> scale conversions and the available scales helpers. For latter case we also provide the time-tables, and actually all the APIs should be usable by setting the time multiplier to 1. (not testeted thoroughly though). The patch 1/7 introduces the helpers for creating/dropping a test device for devm-tests. It can be applied alone. The patch 4/7 (IIO GTS tests) also depends on the patch 1/7 (and also other patches in the series). Rest of the series should be Ok to be applied with/without the patches 1/7 and 4/7 - although the 4/7 (which depends on 1/7) would be "nice to have" together with the rest of the series for the testability reasons. Revision history: v5 => v6: - Just a minor fixes in iio-gts-helpers and bu27034 driver. - Kunit device helper for a test device creation. - IIO GTS tests use kunit device helper. v4 => v5: Mostly fixes to review comments from Andy and Jonathan. - more accurate change-log in individual patches - copy code from DRM test helper instead of moving it to simplify merging - document all exported GTS helpers. - inline a few GTS helpers - use again Milli lux for the bu27034 with RAW IIO_LIGHT channel and scale - Fix bug from added in v4 bu27034 time setting. v3 => v4: (Still mostly fixes to review comments from Andy and Jonathan) - more accurate change-log in individual patches - dt-binding and maintainer patches unchanged. - dropped unused helpers and converted ones currently used only internally to static. - extracted "dummy device" creation helpers from DRM tests. - added tests for devm APIs - dropped scale for PROCESSED channel in BU27034 and converted mLux values to luxes - dropped channel 2 GAIN setting which can't be done due to HW limitations. v2 => v3: (Mostly fixes to review comments from Andy and Jonathan) - dt-binding and maintainer patches unchanged. - iio-gts-helper tests: Use namespaces - iio-gts-helpers + bu27034 plenty of changes. See more comprehensive changelog in individual patches. RFCv1 => v2: dt-bindings: - Fix binding file name and id by using comma instead of a hyphen to separate the vendor and part names. gts-helpers: - fix include guardian - Improve kernel doc for iio_init_iio_gts. - Add iio_gts_scale_to_total_gain - Add iio_gts_total_gain_to_scale - Fix review comments from Jonathan - add documentation to few functions - replace 0xffffffffffffffffLLU by U64_MAX - some styling fixes - drop unnecessary NULL checks - order function arguments by in / out purpose - drop GAIN_SCALE_ITIME_MS() - Add helpers for available scales and times - Rename to iio-gts-helpers gts-tests: - add tests for available scales/times helpers - adapt to renamed iio-gts-helpers.h header bu27034-driver: - (really) protect read-only registers - fix get and set gain - buffered mode - Protect the whole sequences including meas_en/meas_dis to avoid messing up the enable / disable order - typofixes / doc improvements - change dropped GAIN_SCALE_ITIME_MS() to GAIN_SCALE_ITIME_US() - use more accurate scale for lux channel (milli lux) - provide available scales / integration times (using helpers). - adapt to renamed iio-gts-helpers.h file - bu27034 - longer lines in Kconfig - Drop bu27034_meas_en and bu27034_meas_dis wrappers. - Change device-name from bu27034-als to bu27034 MAINTAINERS: - Add iio-list --- Matti Vaittinen (7): dt-bindings: iio: light: Support ROHM BU27034 iio: light: Add gain-time-scale helpers kunit: Add kunit wrappers for (root) device creation iio: test: test gain-time-scale helpers MAINTAINERS: Add IIO gain-time-scale helpers iio: light: ROHM BU27034 Ambient Light Sensor MAINTAINERS: Add ROHM BU27034 .../bindings/iio/light/rohm,bu27034.yaml | 46 + MAINTAINERS | 14 + drivers/iio/Kconfig | 3 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-gts-helper.c | 1057 ++++++++++++ drivers/iio/light/Kconfig | 14 + drivers/iio/light/Makefile | 1 + drivers/iio/light/rohm-bu27034.c | 1496 +++++++++++++++++ drivers/iio/test/Kconfig | 14 + drivers/iio/test/Makefile | 1 + drivers/iio/test/iio-test-gts.c | 517 ++++++ include/kunit/device.h | 18 + include/linux/iio/iio-gts-helper.h | 206 +++ lib/kunit/Makefile | 3 +- lib/kunit/device.c | 36 + 15 files changed, 3426 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml create mode 100644 drivers/iio/industrialio-gts-helper.c create mode 100644 drivers/iio/light/rohm-bu27034.c create mode 100644 drivers/iio/test/iio-test-gts.c create mode 100644 include/kunit/device.h create mode 100644 include/linux/iio/iio-gts-helper.h create mode 100644 lib/kunit/device.c base-commit: eeac8ede17557680855031c6f305ece2378af326 -- 2.39.2 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]

2 years, 3 months

4
9
0 0

[PATCH v2 0/2] regmap: Initial KUnit coverage

by Mark Brown

This series provides some initial KUnit coverage for regmap, covering most of the interfaces that operate at the register level using an instrumented RAM backed bus type. Without the current regmap tree the paging tests will fail as the RAM backed regmap doesn't support the required operations. Changes in v2: - Add a test for regcache_drop_region(). - Add a stress test for inserting registers into a sparse cache. - Link to v1: https://lore.kernel.org/r/20230324-regmap-kunit-v1-0-62ef9cfa9b89@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (2): regmap: Add RAM backed register map regmap: Add some basic kunit tests drivers/base/regmap/Kconfig | 10 + drivers/base/regmap/Makefile | 2 + drivers/base/regmap/internal.h | 19 + drivers/base/regmap/regmap-kunit.c | 736 +++++++++++++++++++++++++++++++++++++ drivers/base/regmap/regmap-ram.c | 85 +++++ 5 files changed, 852 insertions(+) --- base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65 change-id: 20230324-regmap-kunit-bb3c3e81e35c Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 3 months

1
3
0 0

[PATCH 0/2] regmap: Initial KUnit coverage

by Mark Brown

This series provides some initial KUnit coverage for regmap, covering most of the interfaces that operate at the register level using an instrumented RAM backed bus type. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (2): regmap: Add RAM backed register map regmap: Add some basic kunit tests drivers/base/regmap/Kconfig | 10 + drivers/base/regmap/Makefile | 2 + drivers/base/regmap/internal.h | 19 ++ drivers/base/regmap/regmap-kunit.c | 631 +++++++++++++++++++++++++++++++++++++ drivers/base/regmap/regmap-ram.c | 85 +++++ 5 files changed, 747 insertions(+) --- base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65 change-id: 20230324-regmap-kunit-bb3c3e81e35c Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 3 months

2
5
0 0

[PATCH 5.4] selftests: Fix the executable permissions for fib_tests.sh

by Rishabh Bhatnagar

Commit 04a331c9dd66 reverted change 2537b637eac0 (ipv4: Fix incorrect route flushing when source address is deleted) that added the fib_tests.sh file back with wrong permissions. Fix that in this commit. Signed-off-by: Rishabh Bhatnagar <risbhat(a)amazon.com> --- tools/testing/selftests/net/fib_tests.sh | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 tools/testing/selftests/net/fib_tests.sh diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh old mode 100644 new mode 100755 -- 2.39.2

2 years, 3 months

2
1
0 0

selftests: net: l2tp.sh regression starting with 6.1-rc1

by Andrea Righi

I noticed that l2tp.sh net selftest is failing in recent kernels with the following error: RTNETLINK answers: Protocol not supported See also: https://bugs.launchpad.net/bugs/2013014 Apprently the module lt2p_ipv6 is not automatically loaded when the test is trying to create an l2tp ipv6 tunnel. I did a bisect and found that the offending commit is this one: 65b32f801bfb ("uapi: move IPPROTO_L2TP to in.h") I've temporarily reverted this commit for now, any suggestion on how to fix this properly? Thanks, -Andrea

2 years, 3 months

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror