Messages in this thread | | | Date | Sun, 11 Feb 2024 20:52:29 -0800 | From | Guenter Roeck <> | Subject | Re: Linux 6.8-rc4 |
| |
On Sun, Feb 11, 2024 at 12:36:02PM -0800, Linus Torvalds wrote: > Commit counts and contents look normal for this phase of the release, > nothing here really stands out. > > Sure, we've got a ntfs3 fix dump, which shows up a bit in the stats, > but the bulk is all the usual suspects: drivers (particularly gpu and > networking) and core networking. > > The rest is the usual random collection of fixes all over: other > drivers, some architecture fixes (mainly x86 and RISC-V), and some > core vm and tracing noise. And selftests. > > Please continue testing, >
Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 549 pass: 547 fail: 2 Unit test results: pass: 161894 fail: 968
Unit test failures look like a lot, but it is mostly the same set of tests failing in several or even all test runs. Some of the tests fail due to a problem with the test, but there are also several bugs in the tested code. Note that some of the unit test failures are old; I only recently updated my scripts to check unit test results.
Almost all problems are fixed in the 'testing' branch at git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
Guenter
======
Runtime crashes ===============
an385:mps2_defconfig:mps2-an385:initrd --------------------------------------
an385 does not support unaligned accesses, but test_ip_fast_csum expects it.
Fix: https://lore.kernel.org/lkml/20240207-fix_sparse_errors_checksum_tests-v6-0-4caa9629705b@rivosinc.com/
See additional information below about checksum unit test failures.
xtensa:de212:kc705-nommu:nommu_kc705_defconfig ----------------------------------------------
Crash in kunit_iov_iter unit test if CONFIG_TEST_IOV_ITER is enabled.
BUG: failure at mm/nommu.c:318/vmap()! Kernel panic - not syncing: BUG!
The test code calls vmap() directly, but vmap() is not supported on nommu systems.
Suggested fix: https://lore.kernel.org/lkml/20240208153010.1439753-1-linux@roeck-us.net/
Warning backtraces ==================
WARNING: inconsistent lock state 6.8.0-rc4 #1 Tainted: G N -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. kworker/0:2/39 [HC1[1]:SC0[2]:HE0:SE0] takes: ef792074 (&syncp->seq#2){?...}-{0:0}, at: sun8i_dwmac_dma_interrupt+0x9c/0x28c {HARDIRQ-ON-W} state was registered at: lock_acquire+0x11c/0x368 __u64_stats_update_begin+0x104/0x1ac stmmac_xmit+0x4d0/0xc58 dev_hard_start_xmit+0xc4/0x2a0 sch_direct_xmit+0xf8/0x30c __dev_queue_xmit+0x400/0xcc4 ip6_finish_output2+0x254/0xafc mld_sendpack+0x260/0x5b0 mld_ifc_work+0x274/0x588 process_one_work+0x230/0x604 worker_thread+0x1dc/0x494 kthread+0x100/0x120 ret_from_fork+0x14/0x28
Caused by commit 38cc3c6dcc09 ("net: stmmac: protect updates of 64-bit statistics counters.")
Report: https://lore.kernel.org/lkml/ea1567d9-ce66-45e6-8168-ac40a47d1821@roeck-us.net/
Unit test failures ==================
checksum --------
Various checksum tests fail on several machines, with different reasons. Too many to list in detail.
Reports:
https://lore.kernel.org/lkml/ec44bf32-8b66-40c4-bc62-4deed3702f99@roeck-us.net/ https://lore.kernel.org/lkml/9b004c45-45f8-4abb-a24e-bb47b369b1a5@roeck-us.net/ https://lore.kernel.org/lkml/65ed7c95-712c-410b-84f3-58496b0c9649@roeck-us.net/
Suggested fixes:
https://lore.kernel.org/lkml/20240207-fix_sparse_errors_checksum_tests-v6-0-4caa9629705b@rivosinc.com/ https://lore.kernel.org/lkml/20240210175526.3710522-1-linux@roeck-us.net/ https://lore.kernel.org/lkml/20240211160837.2436375-1-linux@roeck-us.net/ https://lore.kernel.org/lkml/20240210191556.3761064-1-linux@roeck-us.net/
Handshake API -------------
# req_destroy works: EXPECTATION FAILED at net/handshake/handshake-test.c:477 Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 00000000 req == c4aef640 not ok 11 req_destroy works
Observed in v6.1.y and later. The maintainer wasn't happy with my suggested fix (see discussion and patch in my 'testing' branch). I am not aware of a pending patch.
Discussion: https://lore.kernel.org/all/20240202164705.6813edf2@kernel.org/T/
regmap ------
Reports: https://lore.kernel.org/lkml/fc1d865d-3e2e-48bc-8cd1-389ec6b15909@roeck-us.net/ https://lore.kernel.org/lkml/dc5e573d-0979-4d7e-ab4a-de18a4711385@roeck-us.net/T/#u
Pending fixes: https://lore.kernel.org/lkml/20240206151004.1636761-2-ben.wolsieffer@hefring.com/ https://lore.kernel.org/lkml/20240211-regmap-kunit-random-change-v3-1-e387a9ea4468@kernel.org/
cpumask -------
Report: https://lore.kernel.org/lkml/e6f0ab85-5bbe-41c1-8976-5ba00044998c@roeck-us.net/raw
Also see https://lore.kernel.org/lkml/Zb0mbHlIud_bqftx@slm.duckdns.org/t/
Caused by commit 0921244f6f4f ("parisc: Only list existing CPUs in cpu_possible_mask") which will need to be reverted. Observed in v6.1.y and later.
stackinit ---------
Seen with m68k:q800 emulation.
# test_char_array_zero: ASSERTION FAILED at lib/stackinit_kunit.c:333 Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false stack fill missed target!? (fill 16 wide, target offset by -12)
# test_char_array_none: ASSERTION FAILED at lib/stackinit_kunit.c:343 Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false stack fill missed target!? (fill 16 wide, target offset by -12)
Report: https://lore.kernel.org/lkml/a0d10d50-2720-4ecd-a2c6-c2c5e5aeee65@roeck-us.net/
| |