Message-ID: <d56f35c3-ce83-4356-bf78-66ed5f99d19f@roeck-us.net>
Date: Sun, 11 Feb 2024 20:52:29 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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/

Powered by blists - more mailing lists