Linux 6.13 compat

[robn]

Motivation and Context

Regular prep for new kernel series.

Description

Astonishingly, there appear to be NO CHANGES required. So for the moment, this PR is simply a placeholder for anything that might come up during the 6.13-rc series.

(I wouldn't normally bump META, but I had to commit something to be allowed to create a PR).

How Has This Been Tested?

Full ZTS runs on 6.13-rc1, rc2, rc3 and rc5 completed successfully.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[tonyhutter]

Astonishingly, there appear to be NO CHANGES required.

😮 wow hopefully that holds true for the rest of the RCs!

[robn]

Test suite passed against 6.13-rc2.

[robn]

Test suite passed against 6.13-rc3.

[robn]

Test suite passed against 6.13-rc5.

[robn]

Alas, rc6 broken twice. The first run had a deadlock between txg_sync and a /usr/sbin/zfs call somewhere. The second run has livelocked in txg_sync. No obvious single test involved. I'll do another run with rc5 to see if it seems right, and if so, will review the rc5->rc6 changes to see what happened.

[robn]

rc5 crashed too

shop login: [21133.659386] Kernel panic - not syncing: buffer modified while frozen!
[21133.659592] CPU: 1 UID: 0 PID: 49649 Comm: dbuf_evict Tainted: P           OE      6.13.0-rc5 #2
[21133.659860] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[21133.660088] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
[21133.660284] Call Trace:
[21133.660370]  <TASK>
[21133.660443]  panic+0x340/0x3a0
[21133.660552]  arc_cksum_verify+0x210/0x210 [zfs]
[21133.660938]  arc_buf_destroy_impl+0x38/0x330 [zfs]
[21133.661212]  arc_buf_destroy+0xf7/0x370 [zfs]
[21133.661474]  ? __pfx_thread_generic_wrapper+0x10/0x10 [spl]
[21133.661658]  dbuf_destroy+0x5d/0x790 [zfs]
[21133.661921]  ? __pfx_thread_generic_wrapper+0x10/0x10 [spl]
[21133.662100]  dbuf_evict_one+0x14a/0x1d0 [zfs]
[21133.662328]  ? __pfx_dbuf_evict_thread+0x10/0x10 [zfs]
[21133.662328]  dbuf_evict_thread+0x128/0x280 [zfs]
[21133.662328]  thread_generic_wrapper+0x62/0x90 [spl]
[21133.662328]  kthread+0xce/0x100
[21133.662328]  ? __pfx_kthread+0x10/0x10
[21133.662328]  ret_from_fork+0x30/0x50
[21133.662328]  ? __pfx_kthread+0x10/0x10
[21133.662328]  ret_from_fork_asm+0x1a/0x30
[21133.662328]  </TASK>

I'll try again, but I'm also low-key wondering if we've changed something (I'm always running these tests against master).

[robn]

And here's a crash on rc5, master @ 18c67d2. It completed a run on rc5 yesterday, this was a second run overnight:

[Fri Jan 10 10:09:43 2025] ZTS run /usr/local/share/zfs/zfs-tests/tests/functional/cache/cache_003_pos
[Fri Jan 10 10:10:09 2025] VERIFY3(vd->vdev_trim_thread == NULL) failed (ffff8c3d6ab24c80 == 0000000000000000)
[Fri Jan 10 10:10:09 2025] PANIC at vdev_trim.c:1703:vdev_trim_l2arc()
[Fri Jan 10 10:10:09 2025] Showing stack for process 2536603
[Fri Jan 10 10:10:09 2025] CPU: 3 UID: 0 PID: 2536603 Comm: spa_async Tainted: P           OE      6.13.0-rc5 #2
[Fri Jan 10 10:10:09 2025] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[Fri Jan 10 10:10:09 2025] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
[Fri Jan 10 10:10:09 2025] Call Trace:
[Fri Jan 10 10:10:09 2025]  <TASK>
[Fri Jan 10 10:10:09 2025]  dump_stack_lvl+0x60/0x80
[Fri Jan 10 10:10:09 2025]  spl_panic+0xfc/0x120 [spl]
[Fri Jan 10 10:10:09 2025]  ? srso_alias_return_thunk+0x5/0xfbef5
[Fri Jan 10 10:10:09 2025]  ? __mutex_lock.constprop.0+0x3f0/0x730
[Fri Jan 10 10:10:09 2025]  ? __pfx_thread_generic_wrapper+0x10/0x10 [spl]
[Fri Jan 10 10:10:09 2025]  vdev_trim_l2arc+0x264/0x2e0 [zfs]
[Fri Jan 10 10:10:09 2025]  spa_async_thread+0x466/0xa40 [zfs]
[Fri Jan 10 10:10:09 2025]  ? __pfx_spa_async_thread+0x10/0x10 [zfs]
[Fri Jan 10 10:10:09 2025]  ? __pfx_thread_generic_wrapper+0x10/0x10 [spl]
[Fri Jan 10 10:10:09 2025]  thread_generic_wrapper+0x62/0x90 [spl]
[Fri Jan 10 10:10:09 2025]  kthread+0xce/0x100
[Fri Jan 10 10:10:09 2025]  ? __pfx_kthread+0x10/0x10
[Fri Jan 10 10:10:09 2025]  ret_from_fork+0x30/0x50
[Fri Jan 10 10:10:09 2025]  ? __pfx_kthread+0x10/0x10
[Fri Jan 10 10:10:09 2025]  ret_from_fork_asm+0x1a/0x30
[Fri Jan 10 10:10:09 2025]  </TASK>

I'll try to reproduce it more reliably, because I still can't really guess if its a recent regression on our side, or it just didn't show up in earlier 6.13 runs because its hard to hit.