MantisBT - Issues

0000663: python3-argcomplete not completing

Thu, 06 Aug 2026 01:10:27 +0000

On AlmaLinux10, python3 scripts in the PATH that utilized the `argcomplete` module and are registered with `register-python-argcomplete` are not auto-completing.

Package version is 3.2.2-4.el10.

0000662: /usr/lib/systemd/system/fwupd.service Unknown lvalues

Wed, 05 Aug 2026 16:54:28 +0000

Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd-refresh.service:20: Unknown lvalue 'ProtectHostname' in section 'Service'
Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd-refresh.service:22: Unknown lvalue 'ProtectKernelLogs' in section 'Service'
Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd.service:22: Unknown lvalue 'ProtectClock' in section 'Service'
Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd.service:25: Unknown lvalue 'ProtectHostname' in section 'Service'
Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd.service:26: Unknown lvalue 'ProtectKernelLogs' in section 'Service'
Aug 04 09:39:07 systemd[1]: /usr/lib/systemd/system/fwupd.service:29: Unknown lvalue 'ProtectProc' in section 'Service'

0000621: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 10

Wed, 05 Aug 2026 15:23:35 +0000

Currently, the maximum queue depth supported for gVNIC on overcommited Gen3+ VMs such as N4 is 1K, whereas the maximum queue depth supported on Gen1/Gen2 VMs is 2K. Customers who are migrating their workloads from N2 to N4 have requested higher queue depth support on N4 VMs.

GVE driver changes to support greater than 1K queue depth for overcommitted Gen3+ have been upstreamed to Linux kernel recently:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a2f19184014f
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=07993df56091

0000622: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 9

Wed, 05 Aug 2026 15:22:21 +0000

0000661: systemd-networkd is not renewing IPv6 default route got from ISP

Tue, 04 Aug 2026 21:50:31 +0000

On my current AlmaLinux 10.2 I moved to systemd-networkd. I use it on a Protectli VP4650 as my Internet Firewall. Works perfect, except the issue with IPv6 default route. What happens:
enp1s0 is connected to WAN, getting the IPs via DHCP and DHCP6 (networkd), but also SLAAC. systemd-networkd is configuring everything correctly. The ISP router is giving a default route with a lifetime of 30 minutes. Now the issue begins. After this 30 minutes, the route is simply removed. Done. systemd-networkd is not renewing, not sending any router solicitation. On the other hand, ISP router is not sending router advertisement. Many ISPs behave like this. So, networkd should track this and manage to renew.
The result is just that IPv6 is not working (for ever, or the router is sending an RA for any other reason) from a clients perspective.

I have not found any hint on github that this will be solved, just a similar bug report, but different use case.

0000478: TCP connection/socket gets stuck and the messages delayed

Fri, 31 Jul 2026 14:00:02 +0000

Hi,

We have a client/server application which was developed a long time ago. It has been running in production for more than 10 years. The client is a Windows application written in C++, and the server-side component is written in Java 8.

This client/server software has been working fine for a long time on Linux servers. Currently, we use AlmaLinux 9. It was working on AlmaLinux 9 until updating the kernel.

So, when we update the Linux kernel from “5.14.0-362.13.1.el9_3.x86_64” to “kernel-5.14.0-427.31.1.el9_4.x86_64” the application gets unstable: The client drops the connection based due to not receiving messages in the proper time. We notice delays, the client just waiting for the response from the server. We can notice that all messages from the client are delayed on the server-side, the Java application gets the messages with a delay of several seconds. The issue is always reproducible with the new kernel. And if we go back to the old kernel, the problem is gone. We kept running the test for hours in both cases.

Even if we restart clients as well as the server application, the issue does not disappear. Only the full OS reboot can solve the problem.

I can provide PCAP files created by tcpdump tool in both cases: working and non-working scenarios. You can see the delay in the PCAP file and also lot of TCP Window Full messages.

Please investigate the issue that what happened between these two kernel versions. It seems there is an issue in the new kernel. Let us know what has been changed since "5.14.0-362.13.1.el9_3.x86_64" kernel version. An application that was working for a long time on Linux, now gets unstable due to kernel update.

I already reported a bug on the kernel.org website. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219221

You find the PCAP files in the attachment.

Please analyze it and help us to determine why the new kernel behaves differently and causes this weird behaviour. How it can be fixed either in our application or maybe fx is required in the kernel?

Thanks a lot!

Regards,

Zoltan

0000660: mirrorlist option in url kickstart command broken

Wed, 29 Jul 2026 19:10:31 +0000

https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#url suggest that, like with the `repo` command, the `url` command allows a `mirrorlist` option, but it fails every time.

0000659: dnf/rpm segfault via use-after-free in sqlite log callback (history.sqlite)

Wed, 29 Jul 2026 15:38:15 +0000

`dnf` intermittently segfaults when opening `/var/lib/dnf/history.sqlite` (and potentially any other sqlite database opened after the rpmdb) with a `Segmentation fault (core dumped)`. This is caused by a known upstream rpm bug:
rpm registers a **process-global** sqlite log callback (`sqlite3_config(SQLITE_CONFIG_LOG, errCb, rdb)`)
tied to a specific `rpmdb` handle. If that handle is later freed and a *different* sqlite database (e.g. `history.sqlite`) triggers a log message (commonly a WAL-recovery notice), sqlite invokes the stale callback and dereferences freed memory, causing a crash.

Upstream rpm fixed this by removing the callback entirely:
https://github.com/rpm-software-management/rpm/commit/ea3187cfcf9cac87e5bc5e7db79b0338da9e355e

This fix does not appear to be present in `rpm-4.16.1.3-40.el9` (see "Verification" below).

## Environment

- OS: AlmaLinux 9 (AlmaLinux release 9.8 (Olive Jaguar))
- `rpm -q rpm`: `rpm-4.16.1.3-40.el9.x86_64`
- `rpm -q sqlite-libs`: `sqlite-libs-3.46.1-1.el9.x86_64`
- `rpm -q dnf python3-libdnf`: `libdnf-0.69.0-18.el9.alma.1`, dnf version (dnf-0:4.14.0-34.el9_8.alma.1.noarch)

Related thread: https://forums.almalinux.org/t/dnf-segmentation-fault-core-dumped/5528/3

0000658: [AlmaLinux][MANA][Backport][Distros] net: mana: Add handler for sriov configure

Tue, 28 Jul 2026 12:39:13 +0000

Request backport of the following patch to all kernel versions accepting new features.

Summary:
This adds PF/SRIOV feature.

Patch URL:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=ce6b4d3216b63f902bb8e9695ee6c10c83415f65

0000657: [AlmaLinux][MANA][Backport][Distros] porting patch: RDMA: Change capability fields in ib_device_attr from int to u32

Tue, 28 Jul 2026 11:33:31 +0000

Request backport of the following patch.

Summary:
It is an optimization in the code flow.
Updates incorrect assignments of int -> u32 across the code.

Patch URL:

https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=eebd08d91ddbd6

0000643: [AlmaLinux][Backport][MANA] net: mana: Fall back to standard MTU when PF reports adapter_mtu of 0

Tue, 28 Jul 2026 10:54:10 +0000

Request backport of the following bug fix patch.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6bd81a5b4e0d

0000656: ELevate-NG 9→10: PES Split event (id 20203) removes samba/sssd stack — discards available AlmaLinux 10 samba-common-libs

Mon, 27 Jul 2026 11:25:44 +0000

Upgrading AlmaLinux 9.8 → 10 with ELevate-NG on an x86_64_v2 host. leapp drops the samba/sssd stack during the upgrade. The trigger is a Package Evolution (PES) Split event that makes leapp discard samba-common-libs — even though AlmaLinux 10 does ship it — and everything that depends on it cascades out.

Environment

- Source: AlmaLinux 9.8, target AlmaLinux 10.2 (x86_64_v2)
- ELevate-NG repo: https://repo.almalinux.org/elevate/testing/elevate-ng-el9.repo
- leapp-upgrade-el9toel10 0.24.0, leapp-data-almalinux-x86_64_v2-0.13-6.el9.20260622

Symptom — verified by rpm -qa before/after a real upgrade. These are removed with no replacement:

samba-common-libs
samba-client-libs
samba-common
cifs-utils
sssd
sssd-ad
sssd-ipa
sssd-common-pac

Root cause

pes-events.json has an action: 4 (Split):

samba-common-libs → samba-core-libs + samb

The leapp log confirms it applies this:

Applying event 20203 (SPLIT): replacing samba-common-libs with samba-core-libs, samba-ndr-libs

Because of that event, leapp treats samba-common-libs as replaced and excludes it from the target set. But:

1. samba-core-libs / samba-ndr-libs don't exist in AlmaLinux 10 — so nothing replaces it, and
2. samba-common-libs itself does exist in AlmaLinux 10 and is perfectly installable:

# AlmaLinux 10.2 BaseOS (x86_64_v2)
samba-common-libs 4.23.5-107.el10_2 # present (also -109)
samba-core-libs → not found
samba-ndr-libs → not found

So leapp discards an available package for nonexistent successors. On el10, samba-common-libs is a hard dependof much of the stack, so the exclusion cas

samba-common-libs ← excluded by the split (root cause)
↑ Requires
samba-client-libs → removed
↑ Requires
sssd-ad, sssd-ipa → removed
cifs-utils (via libwbclient → samba-client-libs) → removed samba-common, sssd, sssd-common-pac → remo
Why the event exists: the split is real upStream 10 with samba 4.24.3(samba-core-libs/samba-ndr-libs 4.24.3-100.el10). But AlmaLinux 10.2 still ships pre-split samba 4.23.5, so the Stream-derived PES event fires against a target that hasn't made the split.

Question: what's the recommended handling? It seems the samba Split event should be gated/held in leapp-data-almalinux until AlmaLinux 10 actually ships the split (samba 4.24.3+), so leapp keeps the existing samba-common-libs instead of dropping it. ake a Split event conditional on the targetpackage actually being present?

0000655: Anaconda text-mode installer uses an abnormally large 16x32 console font on AlmaLinux 9.8

Mon, 20 Jul 2026 19:24:30 +0000

During an automated AlmaLinux 9.8 x86_64 installation using iPXE and Kickstart text mode, the Anaconda interface on TTY1 switches to an abnormally large 16x32 console font.

Environment:

- Distribution: AlmaLinux 9.8
- Architecture: x86_64
- Virtualization platform: Proxmox VE 8.4.19
- Installation method: iPXE with Kickstart
- Kickstart mode: text
- Installation locale: en_US.UTF-8
- Anaconda version: anaconda-34.25.7.14-1.el9.alma.1
- Virtual framebuffer driver: bochs-drmdrmfb
- Framebuffer resolution: 1280x800

The framebuffer resolution is correct and the issue is limited to the virtual console used by Anaconda.

Measured console settings:

TTY1, where Anaconda is running:

- Terminal size: 25 rows and 80 columns
- Console font: 16x32x512

TTY2, the installer shell:

- Terminal size: 50 rows and 160 columns
- Console font: 8x16x512

Both virtual consoles use the same 1280x800 framebuffer. Therefore, the problem is not caused by a low framebuffer resolution or browser/noVNC scaling. Anaconda explicitly changes the font only on TTY1.

The Anaconda log confirms the font change:

console fonts found for locale en_US.UTF-8: ['eurlatgr']
setting console font to eurlatgr
console font set successfully to eurlatgr

After Anaconda loads eurlatgr on TTY1, the console changes from the normal 8x16 font to 16x32. This halves the number of available rows and columns and makes the text-mode installer interface abnormally large.

The same Proxmox environment does not show this behavior when installing AlmaLinux 9.7 or AlmaLinux 10.2. The issue is reproducible with AlmaLinux 9.8.

0000654: iptables-nft-1.8.11-15.el10_2 pulls kernel-debug packages during fresh AlmaLinux 10.2 installation

Mon, 20 Jul 2026 18:42:11 +0000

A fresh AlmaLinux 10.2 x86_64 installation performed by Anaconda installs both the normal kernel and the complete kernel-debug package set.

Environment:

- Distribution: AlmaLinux 10.2
- Architecture: x86_64
- Installation method: Anaconda
- Installation media: AlmaLinux 10.2 x86_64 Boot ISO
- Affected package: iptables-nft-1.8.11-15.el10_2.x86_64
- Kernel version: 6.12.0-211.34.1.el10_2.x86_64

Actual result:

The installation contains both the normal kernel:

kernel-core-6.12.0-211.34.1.el10_2.x86_64

and the complete debug kernel package set:

kernel-debug-core-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-core-6.12.0-211.34.1.el10_2.x86_64
kernel-debug-modules-extra-6.12.0-211.34.1.el10_2.x86_64

The first DNF/Anaconda transaction contains:

Install iptables-libs-1.8.11-15.el10_2.x86_64 @anaconda
Install iptables-nft-1.8.11-15.el10_2.x86_64 @AppStream
Install kernel-debug-core-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-core-6.12.0-211.34.1.el10_2.x86_64 @anaconda
Install kernel-debug-modules-extra-6.12.0-211.34.1.el10_2.x86_64 @anaconda

This proves that the debug kernel packages were selected during the initial installation. They are not leftovers from an earlier iptables version or a previous system update.

Expected result:

A normal AlmaLinux installation should install only the normal kernel variant. The kernel-debug packages should not be installed unless explicitly selected by the user.

0000653: gdm-1:47.0-21.el10_2 regression: Login authentication failure with kernel-6.12.0-211.34.1 (gnome-keyring-daemon socket unavailab

Fri, 17 Jul 2026 13:30:11 +0000

gdm version 1:47.0-21.el10_2 introduces a regression when running on kernel 6.12.0-211.34.1.el10_2. During login, GDM flashes to console and authentication fails initially, with the following errors in systemd journal:

pam_unix(gdm-password:auth): authentication failure
gkr-pam: unable to locate daemon control file
gkr-pam: stashed password to try later in open session

The login eventually succeeds 0000007:0000009 seconds later after GDM restarts. Reverting to the previous gdm version (1:47.0-20.el10_2) resolves the issue on the same kernel.

0000652: kernel-6.12.0-211.34.1 regression: Login authentication failure due to gnome-keyring-daemon socket unavailability

Fri, 17 Jul 2026 13:05:21 +0000

Kernel 6.12.0-211.34.1 introduces a regression in the login flow. When attempting to log in via GDM, the display manager briefly flashes to console and either fails authentication or requires multiple login attempts. Kernel 6.12.0-211.33.1 works without issues.

Lenovo X1 Carbon.

0000651: [AlmaLinux][MANA][Backport][Distros] Patch: net: mana: Add Interrupt Moderation support

Tue, 14 Jul 2026 06:33:38 +0000

Request backport of the following patch.

Problem Summary
This patch implements driver support for the feature: Static and Dynamic Interrupt Moderation (DIM).

Impact on Customer VMs/BMs
Without this patch the Interrupt Moderation won't be available.
Patch Criticality
Medium (High for C200 system) -- Backport as far back as possible for LTS kernel versions if there is no merge conflicts. Mandatory for versions which has C200 systems.
Classification
New feature
Upstream reference
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=433f482add31b8f81c79fcafa739a5e7ab71daf2

0000644: AlmaLinux 10: advisories removed from errata.full.json while their HTML pages remain published — which source is authoritative?

Tue, 14 Jul 2026 03:14:19 +0000

I help maintain the data pipeline of an open-source vulnerability scanner
https://github.com/future-architect/vuls/ , which consumes https://errata.almalinux.org/10/errata.full.json.

Around 2026-05-19..26, the AlmaLinux 10 errata feed went through a large
re-curation:

- Many published ALSA advisories disappeared from errata.full.json.
Our snapshot of 2026-05-21 contained 279 advisories; during that window
the feed shrank to roughly 60, and it has since regrown to 264
(as of 2026-07-02).
- Some advisories were re-issued under new IDs, in some cases more than
once. Example: CVE-2025-13601 was covered by ALSA-2026:0975, which
disappeared and is now covered by ALSA-2026:18344.
- However, the static HTML pages of the removed advisories are still
published: they return HTTP 200 with full content, and they are still
listed in the directory index at https://errata.almalinux.org/10/
(504 ALSA-*.html files vs 264 entries in the current feed).

Impact: comparing our 2026-05-21 snapshot with the current feed, the
removed advisories referenced 434 unique CVEs, of which only 58 are still
referenced by any advisory in the current feed. The remaining 376 CVEs are
no longer covered at all. For downstream consumers of the feed (security
scanners, SBOM/VEX tooling), this is an effective loss of detection
coverage for AlmaLinux 10, while the same advisories still look
"published" on the website.

Questions:
1. Was the removal of these advisories from errata.full.json an
intentional retirement/re-curation, or a side effect of how the feed
is regenerated?
2. Which source should downstream consumers treat as authoritative:
errata.full.json, the HTML pages, or the updateinfo.xml shipped in
the repositories?
3. If the retirement is intentional, could the corresponding HTML pages
be removed or marked as retired, so the two sources stay consistent?
Conversely, if it is not intentional, could the feed be regenerated
to include them again?
4. Is there any announcement or changelog describing this re-curation
that we could reference?

Other examples absent from the feed but live as HTML:
- https://errata.almalinux.org/10/ALSA-2025-21013.html (libssh)
- https://errata.almalinux.org/10/ALSA-2025-23479.html (openssh)
- https://errata.almalinux.org/10/ALSA-2026-13515.html (freeipmi)
- https://errata.almalinux.org/10/ALSA-2026-3517.html (thunderbird)

0000650: [AlmaLinux][MANA][Backport][Distros] 2 Patch set: Fix MANA RX with bounce buffering

Mon, 13 Jul 2026 13:59:57 +0000

Request backport of the following bug fix patch to all kernels versions that has the bottom dependent patch.

Problem Summary
This patch set fixes MANA NIC connection with CVM and bounce buffering.

Regression Issue: Severity P0.

Patch reference:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c72a0f09c57f92113df69f9b902d11c9e4b132f5
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2e2a83b4998af4384e677d3b2ac08565274279bf

So only kernels with this patch 730ff06d3f5c need this fixes

Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")

0000649: kernel BUG in folio_end_writeback via cifs_writepages on close()

Mon, 13 Jul 2026 12:42:49 +0000

--------------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------------

5.14.0-687.15.1.el9_8 (also reproduced on -687.17.1 and -687.20.1) — kernel BUG
at mm/filemap.c:1593 in folio_end_writeback, reached from cifs_writepages during
a synchronous writeback flush issued by the CIFS code itself: in most dumps from
cifs_flush on close(), in two dumps from cifs_open on open(). Seen in the same
event are a refcount_warn_saturate (refcount underflow / use-after-free) in the
CIFS async write path and a socket send failure (Error -32 / EPIPE) to the
server. The crash(8) disassembly confirms the BUG is the
"if (!__folio_end_writeback(folio)) BUG();" case — i.e. writeback is ended on a
folio whose writeback flag was already clear (a double-completion of writeback).

The same underlying corruption also manifests as a second signature: a general
protection fault on a non-canonical address with RIP in unlock_page+0x5, again
directly under cifs_writepages, with the identical refcount-WARN + Error -32
preamble (4 of 17 dumps).

The crash reproduces on fully UNTAINTED kernels: two of the four affected
machines carry no out-of-tree modules at all ("Not tainted" in the dumps).

Severity: crash / kernel panic
Category: kernel

--------------------------------------------------------------------------------
FOUR INDEPENDENT MACHINES, THREE KERNEL BUILDS, IDENTICAL SIGNATURE
--------------------------------------------------------------------------------

The panic has now been captured on four physically different servers (three
different Dell models) across three el9_8 kernel builds. 17 kdumps total. The
call traces match down to the same symbol offsets.

hostA
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernels : 5.14.0-687.15.1.el9_8
Comm : dask worker [tc (e.g. PID 70950, CPU 22)
Hardware: 40 CPUs, 766.6 GB RAM
CIFS : cache=none
Taint : P OE (NVIDIA out-of-tree module loaded)
Dumps : 5 (2026-06-20 .. 2026-06-23)

hostB
Server : Dell PowerEdge R750xa, BIOS 1.20.2
Kernels : 5.14.0-687.15.1.el9_8 and 5.14.0-687.17.1.el9_8
Comm : pt_main_thread / python
Hardware: 24 CPUs, 383.2 GB RAM
CIFS : cache=strict
Taint : P OE (NVIDIA out-of-tree module loaded)
Dumps : 6 (2026-06-20 .. 2026-07-11; the three July dumps are on
-687.17.1)

hostC
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernels : 5.14.0-687.15.1.el9_8 and 5.14.0-687.20.1.el9_8
Comm : dask worker [tc
Taint : NOT TAINTED — no out-of-tree modules
Dumps : 3 (all 2026-07-03; one of them on -687.20.1)

hostD
Server : Dell PowerEdge R640, BIOS 2.26.1
Kernels : 5.14.0-687.20.1.el9_8
Comm : python
Taint : NOT TAINTED — no out-of-tree modules
Dumps : 3 (all 2026-07-03)

Kernel build string (hostA/hostB June dumps):

Linux version 5.14.0-687.15.1.el9_8.x86_64
(mockbuild@x64-builder01.almalinux.org) ...
#1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:51:45 EDT 2026

Four different servers of three models crashing at the identical instruction
with the identical call chain points to a software defect, not a per-machine
hardware fault.

--------------------------------------------------------------------------------
NOT AN OUT-OF-TREE-MODULE ISSUE — UNTAINTED REPRODUCTIONS
--------------------------------------------------------------------------------

Earlier dumps (hostA/hostB) carried the "P ... OE" taint from the NVIDIA driver.
The six hostC/hostD dumps rule that out as a factor: all of them crash with

CPU: 10 PID: 97317 Comm: dask worker [tc Kdump: loaded Not tainted
5.14.0-687.15.1.el9_8.x86_64 #1 (hostC)
CPU: 12 PID: 6801 Comm: python Kdump: loaded Not tainted
5.14.0-687.20.1.el9_8.x86_64 #1 (hostD)

On the subsequent BUG oops line these hosts show "Tainted: G W" — the W is set
by the refcount_warn_saturate WARNING that fires immediately before the BUG in
the very same event; G means no proprietary/out-of-tree modules were ever
loaded. The bug therefore reproduces on a pristine distribution kernel.

--------------------------------------------------------------------------------
WHAT THE DUMPS SHOW
--------------------------------------------------------------------------------

In all 17 dumps the crash is a two-part event on the same CPU/PID. The two
parts are shown below in the order the report discusses them; the order in
which they were actually printed to the kernel log varies (see "A note on
ordering" at the end of this section).

1) refcount underflow in the CIFS async write path

refcount_t: underflow; use-after-free.
WARNING: CPU: PID: at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
... Tainted: P OE 5.14.0-687.15.1.el9_8.x86_64 (hostA/hostB)
... Not tainted 5.14.0-687.20.1.el9_8.x86_64 (hostC/hostD)
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:refcount_warn_saturate+0xba/0x110
Call Trace:
refcount_warn_saturate+0xba/0x110
cifs_call_async+0x1ee/0x330 [cifs]
smb2_async_writev+0x473/0x6f0 [cifs]
? __pfx_cifs_writedata_release+0x10/0x10 [cifs]
cifs_writepages+0x52f/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

The release function on the stack is cifs_writedata_release — i.e. the object
whose refcount saturates/underflows is the CIFS writedata associated with this
writeback.

2) socket send failure, and the BUG

CIFS: VFS: \\ Error -32 sending data on socket to server
------------[ cut here ]------------
kernel BUG at mm/filemap.c:1593!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
... Tainted: P W OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:folio_end_writeback+0x7d/0x80
Call Trace:
folio_end_writeback+0x7d/0x80
cifs_writepages+0x998/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

BUG at mm/filemap.c:1593 inside folio_end_writeback means writeback is being
ended on a folio that is no longer flagged as under writeback — the folio's
writeback state has already been completed/torn down once. Combined with the
refcount underflow on the CIFS writedata and the socket send failure
(Error -32 / EPIPE) seen in the same event, the signature is a use-after-free
/ double-completion of the writeback in the SMB2 async write path, occurring
during a synchronous CIFS flush. We read the failed/aborted send during
writeback as the likely trigger, but state this as a hypothesis rather than a
proven sequence (see "A note on ordering").

Matching offsets on all machines: cifs_call_async+0x1ee, smb2_async_writev+0x473,
cifs_writepages+0x52f (send path) and +0x998 (writeback-end path),
folio_end_writeback+0x7d, BUG at mm/filemap.c:1593.

Socket error code: across all 17 dumps the ONLY error ever logged is
"Error -32 sending data on socket to server" (20 occurrences total). No other
error code appears.

A note on ordering

The three symptoms — the refcount underflow (refcount_warn_saturate), the
socket send failure (CIFS: VFS: ... Error -32 sending data on socket), and the
BUG in folio_end_writeback — appear together in every dump, but their PRINTED
order is not stable (it differs between hosts and even between different dumps
of the same host). We therefore do NOT claim a proven cause-and-effect order
between the send failure and the refcount underflow. printk ordering on a
many-CPU box under load does not necessarily reflect the true event timeline,
and the send-error and refcount messages originate in different contexts. What
is consistent across all dumps is the end state: a CIFS writeback whose state
is ended twice (__folio_end_writeback() returns false -> BUG), in a
synchronous CIFS flush path, in the presence of a failing/aborted SMB2 send.
The "failed send during writeback triggers a bad writeback completion"
reading is our best-supported hypothesis, not a fact the logs establish on
their own.

--------------------------------------------------------------------------------
SECOND MANIFESTATION — GPF ON A NON-CANONICAL ADDRESS IN unlock_page
--------------------------------------------------------------------------------

4 of the 17 dumps (hostB x3, hostA x1) do not reach the BUG in
folio_end_writeback but die a few instructions earlier with a general
protection fault, dereferencing a garbage folio pointer:

general protection fault, probably for non-canonical address
0xd0bbf42d90685ec1: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:unlock_page+0x5/0x40
Call Trace:
? unlock_page+0x5/0x40
cifs_writepages+0x585/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
__filemap_fdatawrite_range+0x54/0x80
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
filp_flush+0x2e/0x80
__x64_sys_close+0x2e/0x80

Preamble (refcount_warn_saturate + Error -32) and entry path are identical to
the BUG variant; only the point of death differs (unlock_page on an
already-freed/poisoned folio vs. folio_end_writeback on a folio whose writeback
bit is already clear). Both are consistent with the same use-after-free /
double-completion of the CIFS writeback state.

--------------------------------------------------------------------------------
NOT ONLY close() — SECOND SYSCALL ENTRY PATH VIA open()
--------------------------------------------------------------------------------

15 of the 17 dumps enter the fatal writeback via the flush on close()
(cifs_flush -> filp_flush -> __x64_sys_close). Two hostC dumps (both
2026-07-03, one of them on an untainted -687.15.1, comm "dask worker") enter it
via open() instead:

do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
__filemap_fdatawrite_range+0x54/0x80
filemap_write_and_wait_range+0x3e/0xb0
cifs_open+0x56e/0xc70 [cifs]
do_dentry_open+0x14f/0x440
do_open+0x219/0x400
path_openat+0x110/0x280
do_filp_open+0xb0/0x160
do_sys_openat2+0x96/0xd0
__x64_sys_openat+0x53/0xa0

The defect is therefore not tied to the close() syscall specifically, but to
the synchronous filemap_write_and_wait_range() flushes that the CIFS code
issues itself (so far observed from cifs_flush and cifs_open). We have NOT
observed the crash from fsync/msync, background writeback (kworker/flush) or
memory reclaim in any dump.

--------------------------------------------------------------------------------
BOTH CACHE MODES AFFECTED
--------------------------------------------------------------------------------

hostA and hostB run different CIFS cache modes, and each crashed with the same
confirmed signature:

- hostA (R740): cache=none
- hostB (R750xa): cache=strict

This is visible in the stacks themselves. On hostB (cache=strict), the writeback
path goes through cifs_strict_writev:

cifs_writepages+0x52f/0xbc0 [cifs]
? generic_perform_write+0x14c/0x210
do_writepages+0xd5/0x1b0
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
...
cifs_writepages+0x998/0xbc0 [cifs]
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]

The cifs_strict_writev frame is present on hostB and absent on hostA, confirming
the two crashes reach the same folio_end_writeback double-completion through two
different CIFS write paths (strict vs. none). The bug therefore does NOT depend
on a single cache mode; it is in the writeback-completion handling common to
both.

--------------------------------------------------------------------------------
crash(8) ANALYSIS — VERIFIED SOURCE LINE AND FULL KERNEL STACK
--------------------------------------------------------------------------------

crash(8) sessions over the full vmcores of hostA and hostB (with vmlinux
debuginfo for 5.14.0-687.15.1.el9_8) confirm the source line and the complete
in-kernel stack that the redacted dmesg only shows by offset.

The disassembly of folio_end_writeback shows the BUG() at line 1593 is reached
directly from the "if (!__folio_end_writeback(folio)) BUG();" path — i.e.
__folio_end_writeback() returned false because the folio's PG_writeback flag was
already clear:

1591 folio_get(folio);
1592 if (!__folio_end_writeback(folio))
... call __folio_end_writeback ; test %al,%al ; je <+125>
1593 BUG();
0xffffffff8137921d <+125>: ud2

Resolved kernel-side backtrace (hostA; hostB is identical bar addresses):

[exception RIP: folio_end_writeback+125]
0000008 cifs_writepages [cifs]
0000009 do_writepages
0000010 filemap_fdatawrite_wbc
0000011 __filemap_fdatawrite_range
0000012 filemap_write_and_wait_range
#13 cifs_flush [cifs]
0000014 filp_flush
0000015 __x64_sys_close
0000016 do_syscall_64
0000017 entry_SYSCALL_64_after_hwframe

This matches the dmesg-derived signature exactly and pins the BUG to the
__folio_end_writeback()-returns-false (writeback already ended) case.

Note for reviewers: in the slab PAGE lines of the attachments, MAPPING values
of the form dead0000000004xx / dead000000000001 are the normal kernel slab
page-poison marker (page->mapping for a slab page), NOT corruption and NOT a
redaction.

--------------------------------------------------------------------------------
CIFS MOUNT OPTIONS (anonymized)
--------------------------------------------------------------------------------

Requested options (autofs map; same on all hosts):

sec=krb5,cruid=${UID},uid=${UID},gid=${GID},forceuid,forcegid,
iocharset=utf8,vers=3.0,nosuid,nodev,dir_mode=0700,file_mode=0700,
noserverino,cache=none

Effective options after expansion (from the hostA/hostB dumps), anonymized:

hostA (R740) — cache=none:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=none,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

hostB (R750xa) — cache=strict:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=strict,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

Anonymized fields: cruid/uid -> , gid -> , username -> ,
addr -> . All other values are verbatim. The two hosts differ
only in the cache mode (none vs. strict).

Why these may matter to maintainers (context, not a diagnosis):

- cache mode. Same signature under cache=none (hostA) and cache=strict (hostB),
so the bug is not specific to one writeback path; see "Both cache modes
affected".
- vers=3.0 (not 3.1.1) and sec=krb5 narrow down which SMB2/3 code path and
auth path are in use.
- soft, actimeo=1, closetimeo=1. A soft mount with very short attribute/close
timeouts means operations abort with errors sooner under network pressure —
consistent with the Error -32 / "send fails mid-writeback" condition seen in
the dumps.
- rsize/wsize=4194304 (4 MiB). Large I/O sizes, relevant to how writeback is
chunked.

We note these as potentially relevant context; we are not claiming any single
option is the proven cause.

--------------------------------------------------------------------------------
UPSTREAM CONTEXT (known class of bug; exact fix status for el9 is an open
question)
--------------------------------------------------------------------------------

This is consistent with a previously reported class of CIFS writeback-completion
bugs rather than a brand-new defect:

- On the linux-cifs list (Feb 2024), Steve French reported the same call path
(cifs_flush -> filemap_write_and_wait_range -> ... -> folio_end_writeback)
hit under xfstests when writes time out due to repeatedly failing server
reconnects. Matthew Wilcox's reading was that the bug is something failing to
call folio_end_writeback() when it should — i.e. a mismatch in writeback-end
accounting, which is exactly the __folio_end_writeback()-returns-false
signature seen here. Our trigger (Error -32 / EPIPE on the socket send during
the close() flush) is the same "send/reconnect fails mid-writeback" condition.
Thread: https://www.spinics.net/lists/linux-cifs/msg31067.html

- The CIFS writeback path saw significant churn upstream: a two-phase
cifs_writepages_begin / cifs_extend_writeback design (around f3dc1bdb6b0b
"cifs: Fix writeback data corruption"), later a cut-over to netfslib
(3ee1a1fc3981), plus follow-up fixes (e.g. a per-cifs_writepages_begin folio
leak fix by Yang Erkun). Several of these touch exactly the folio/writeback
refcounting on the write path.

We have NOT been able to identify a single specific upstream commit and confirm
whether it is present in or missing from the el9_8 kernels. Note that the crash
reproduces unchanged on 5.14.0-687.20.1.el9_8 (the newest build we have in
production), so whatever fix is needed is still missing as of that build.
Determining whether el9's backport of the CIFS writeback path already contains
the relevant fix (or needs one) is the key question for the maintainers, and
requires checking the el9 kernel changelog against the upstream CIFS/netfs
writeback fixes above. We're happy to provide the full vmcore(s) and test
further.

--------------------------------------------------------------------------------
ATTACHMENTS
--------------------------------------------------------------------------------

14 files — for each of seven representative dumps a vmcore-dmesg (.txt) and the
matching kexec/kdump boot log (.log). Naming: --,
where 151/171/201 = 5.14.0-687.15.1/-687.17.1/-687.20.1.el9_8, "bug" = kernel
BUG at mm/filemap.c:1593, "gpf" = GPF variant in unlock_page, "openat" = BUG
variant entered via open() instead of close():

hostA-151-bug.txt/.log R740, tainted P OE, BUG, close(), 2026-06-23
hostB-151-bug.txt/.log R750xa, tainted P OE, BUG, close(), 2026-06-21
hostB-171-bug.txt/.log R750xa, BUG on -687.17.1, close(), 2026-07-11
hostB-171-gpf.txt/.log R750xa, GPF in unlock_page, close(), 2026-07-09
hostC-151-openat.txt/.log R740, NOT TAINTED, BUG, open() entry, 2026-07-03
hostC-201-bug.txt/.log R740, NOT TAINTED, BUG on -687.20.1, 2026-07-03
hostD-201-bug.txt/.log R640, NOT TAINTED, BUG on -687.20.1, 2026-07-03

Full vmcores for all 17 dumps are retained and available on request.

0000636: kernel BUG in folio_end_writeback via cifs_writepages on close()

Mon, 13 Jul 2026 12:42:49 +0000

--------------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------------

5.14.0-687.15.1.el9_8 — kernel BUG at mm/filemap.c:1593 in folio_end_writeback,
reached from cifs_writepages during the writeback flush on close(). Seen in the
same event are a refcount_warn_saturate (refcount underflow / use-after-free) in
the CIFS async write path and a socket send failure (Error -32 / EPIPE) to the
server. The crash(8) disassembly confirms the BUG is the
"if (!__folio_end_writeback(folio)) BUG();" case — i.e. writeback is ended on a
folio whose writeback flag was already clear (a double-completion of writeback).

Severity: crash / kernel panic
Category: kernel

--------------------------------------------------------------------------------
TWO INDEPENDENT MACHINES, IDENTICAL PANIC
--------------------------------------------------------------------------------

The same panic was captured on two physically different servers running the
identical kernel build. The call traces match down to the same symbol offsets.

hostA
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernel : 5.14.0-687.15.1.el9_8
Comm : dask worker [tc (PID 70950, CPU 22)
Hardware: 40 CPUs, 766.6 GB RAM
CIFS : cache=none

hostB
Server : Dell PowerEdge R750xa, BIOS 1.20.2
Kernel : 5.14.0-687.15.1.el9_8
Comm : pt_main_thread (PID 246362, CPU 21)
Hardware: 24 CPUs, 383.2 GB RAM
CIFS : cache=strict

Kernel build string (both dumps):

Linux version 5.14.0-687.15.1.el9_8.x86_64
(mockbuild@x64-builder01.almalinux.org) ...
#1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:51:45 EDT 2026

Two different server models crashing at the identical instruction with the
identical call chain points to a software defect, not a per-machine hardware
fault. The only taint flag present before the crash is from an out-of-tree
module (NVIDIA, visible in "Modules linked in"); there is no machine-check /
hardware-error taint in either dump.

The two hosts also run different CIFS cache modes (hostA cache=none, hostB
cache=strict) yet hit the identical signature — see "Both cache modes affected"
below.

--------------------------------------------------------------------------------
WHAT THE DUMPS SHOW
--------------------------------------------------------------------------------

In both dumps the crash is a two-part event on the same CPU/PID. The two parts
are shown below in the order the report discusses them; the order in which they
were actually printed to the kernel log varies (see "A note on ordering" at the
end of this section).

1) refcount underflow in the CIFS async write path

refcount_t: underflow; use-after-free.
WARNING: CPU: PID: at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
... Tainted: P OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:refcount_warn_saturate+0xba/0x110
Call Trace:
refcount_warn_saturate+0xba/0x110
cifs_call_async+0x1ee/0x330 [cifs]
smb2_async_writev+0x473/0x6f0 [cifs]
? __pfx_cifs_writedata_release+0x10/0x10 [cifs]
cifs_writepages+0x52f/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

The release function on the stack is cifs_writedata_release — i.e. the object
whose refcount saturates/underflows is the CIFS writedata associated with this
writeback.

2) socket send failure, and the BUG

CIFS: VFS: \\ Error -32 sending data on socket to server
------------[ cut here ]------------
kernel BUG at mm/filemap.c:1593!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
... Tainted: P W OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:folio_end_writeback+0x7d/0x80
Call Trace:
folio_end_writeback+0x7d/0x80
cifs_writepages+0x998/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

BUG at mm/filemap.c:1593 inside folio_end_writeback means writeback is being
ended on a folio that is no longer flagged as under writeback — the folio's
writeback state has already been completed/torn down once. Combined with the
refcount underflow on the CIFS writedata and the socket send failure
(Error -32 / EPIPE) seen in the same event, the signature is a use-after-free
/ double-completion of the writeback in the SMB2 async write path, occurring
during the flush on close(). We read the failed/aborted send during writeback
as the likely trigger, but state this as a hypothesis rather than a proven
sequence (see "A note on ordering").

Matching offsets on both machines: cifs_call_async+0x1ee, smb2_async_writev+0x473,
cifs_writepages+0x52f (send path) and +0x998 (writeback-end path),
folio_end_writeback+0x7d, BUG at mm/filemap.c:1593.

A note on ordering

The three symptoms — the refcount underflow (refcount_warn_saturate), the
socket send failure (CIFS: VFS: ... Error -32 sending data on socket), and the
BUG in folio_end_writeback — appear together in every dump, but their PRINTED
order is not stable (it differs between hosts and even between different dumps
of the same host). We therefore do NOT claim a proven cause-and-effect order
between the send failure and the refcount underflow. printk ordering on a
many-CPU box under load does not necessarily reflect the true event timeline,
and the send-error and refcount messages originate in different contexts. What
is consistent across both dumps is the end state: a CIFS writeback whose state
is ended twice (__folio_end_writeback() returns false -> BUG), in the close()
flush path, in the presence of a failing/aborted SMB2 send. The "failed send
during writeback triggers a bad writeback completion" reading is our
best-supported hypothesis, not a fact the logs establish on their own.

--------------------------------------------------------------------------------
BOTH CACHE MODES AFFECTED
--------------------------------------------------------------------------------

The two hosts run different CIFS cache modes, and each crashed with the same
confirmed signature:

- hostA (R740): cache=none
- hostB (R750xa): cache=strict

This is visible in the stacks themselves. On hostB (cache=strict), the writeback
path goes through cifs_strict_writev:

cifs_writepages+0x52f/0xbc0 [cifs]
? generic_perform_write+0x14c/0x210
do_writepages+0xd5/0x1b0
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
...
cifs_writepages+0x998/0xbc0 [cifs]
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]

The cifs_strict_writev frame is present on hostB and absent on hostA, confirming
the two crashes reach the same folio_end_writeback double-completion through two
different CIFS write paths (strict vs. none). The bug therefore does NOT depend
on a single cache mode; it is in the writeback-completion handling common to
both.

--------------------------------------------------------------------------------
crash(8) ANALYSIS — VERIFIED SOURCE LINE AND FULL KERNEL STACK
--------------------------------------------------------------------------------

crash(8) sessions over the full vmcores (with vmlinux debuginfo for
5.14.0-687.15.1.el9_8) confirm the source line and the complete in-kernel stack
that the redacted dmesg only shows by offset.

The disassembly of folio_end_writeback shows the BUG() at line 1593 is reached
directly from the "if (!__folio_end_writeback(folio)) BUG();" path — i.e.
__folio_end_writeback() returned false because the folio's PG_writeback flag was
already clear:

1591 folio_get(folio);
1592 if (!__folio_end_writeback(folio))
... call __folio_end_writeback ; test %al,%al ; je <+125>
1593 BUG();
0xffffffff8137921d <+125>: ud2

Resolved kernel-side backtrace (hostA; hostB is identical bar addresses):

[exception RIP: folio_end_writeback+125]
0000008 cifs_writepages [cifs]
0000009 do_writepages
0000010 filemap_fdatawrite_wbc
0000011 __filemap_fdatawrite_range
0000012 filemap_write_and_wait_range
#13 cifs_flush [cifs]
0000014 filp_flush
0000015 __x64_sys_close
0000016 do_syscall_64
0000017 entry_SYSCALL_64_after_hwframe

This matches the dmesg-derived signature exactly and pins the BUG to the
__folio_end_writeback()-returns-false (writeback already ended) case.

Note for reviewers: in the slab PAGE lines of the attachments, MAPPING values
of the form dead0000000004xx / dead000000000001 are the normal kernel slab
page-poison marker (page->mapping for a slab page), NOT corruption and NOT a
redaction.

--------------------------------------------------------------------------------
CIFS MOUNT OPTIONS (anonymized)
--------------------------------------------------------------------------------

Requested options (autofs map; same on both hosts):

sec=krb5,cruid=${UID},uid=${UID},gid=${GID},forceuid,forcegid,
iocharset=utf8,vers=3.0,nosuid,nodev,dir_mode=0700,file_mode=0700,
noserverino,cache=none

Effective options after expansion (from the dumps), anonymized:

hostA (R740) — cache=none:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=none,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

hostB (R750xa) — cache=strict:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=strict,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

Anonymized fields: cruid/uid -> , gid -> , username -> ,
addr -> . All other values are verbatim. The two hosts differ
only in the cache mode (none vs. strict).

Why these may matter to maintainers (context, not a diagnosis):

- cache mode. Same signature under cache=none (hostA) and cache=strict (hostB),
so the bug is not specific to one writeback path; see "Both cache modes
affected".
- vers=3.0 (not 3.1.1) and sec=krb5 narrow down which SMB2/3 code path and
auth path are in use.
- soft, actimeo=1, closetimeo=1. A soft mount with very short attribute/close
timeouts means operations abort with errors sooner under network pressure —
consistent with the Error -32 / "send fails mid-writeback" condition seen in
the dumps.
- rsize/wsize=4194304 (4 MiB). Large I/O sizes, relevant to how writeback is
chunked.

We note these as potentially relevant context; we are not claiming any single
option is the proven cause.

--------------------------------------------------------------------------------
UPSTREAM CONTEXT (known class of bug; exact fix status for el9 is an open
question)
--------------------------------------------------------------------------------

This is consistent with a previously reported class of CIFS writeback-completion
bugs rather than a brand-new defect:

- On the linux-cifs list (Feb 2024), Steve French reported the same call path
(cifs_flush -> filemap_write_and_wait_range -> ... -> folio_end_writeback)
hit under xfstests when writes time out due to repeatedly failing server
reconnects. Matthew Wilcox's reading was that the bug is something failing to
call folio_end_writeback() when it should — i.e. a mismatch in writeback-end
accounting, which is exactly the __folio_end_writeback()-returns-false
signature seen here. Our trigger (Error -32 / EPIPE on the socket send during
the close() flush) is the same "send/reconnect fails mid-writeback" condition.
Thread: https://www.spinics.net/lists/linux-cifs/msg31067.html

- The CIFS writeback path saw significant churn upstream: a two-phase
cifs_writepages_begin / cifs_extend_writeback design (around f3dc1bdb6b0b
"cifs: Fix writeback data corruption"), later a cut-over to netfslib
(3ee1a1fc3981), plus follow-up fixes (e.g. a per-cifs_writepages_begin folio
leak fix by Yang Erkun). Several of these touch exactly the folio/writeback
refcounting on the write path.

We have NOT been able to identify a single specific upstream commit and confirm
whether it is present in or missing from 5.14.0-687.15.1.el9_8. Determining
whether el9's backport of the CIFS writeback path already contains the relevant
fix (or needs one) is the key question for the maintainers, and requires checking
the el9 kernel changelog against the upstream CIFS/netfs writeback fixes above.
We're happy to provide the full vmcore(s) and test further.

0000648: gstreamer packages missing qt6 subpackages

Mon, 13 Jul 2026 03:57:55 +0000

Hi!

The package gstreamer1-plugins-good is not build with the qt6 subpackage (gstreamer1-plugins-good-qt6).

This may be enabled by passing --with qt6 to `rpmbuild` or by modifying the spec.

This package is necessary for some qt/kde applications (like kamoso).

Thanks!

0000646: Qemu-img create fails on loop device with sector size 4096

Thu, 09 Jul 2026 13:31:38 +0000

I am getting this issue when trying to convert a qcow2 image to raw on a 4k sector size NVMe disk.
My current qemu-img version is : qemu-img-10.1.0-17.el9_8.3.alma

0000638: samba-4.19.4-16.el8_10.src.rpm fails to build on AlmaLinux 8.10: samba-4.19-redhat.patch cannot be applied

Wed, 08 Jul 2026 08:27:41 +0000

I am trying to rebuild the official samba-4.19.4-16.el8_10.src.rpm package on AlmaLinux 8.10.

The build process fails during the %prep phase while applying the samba-4.19-redhat.patch patch.

The error obtained is:

/usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch

1 out of 3 hunks FAILED -- saving rejects to file lib/util/substitute.c.rej
1 out of 7 hunks FAILED -- saving rejects to file source3/printing/print_generic.c.rej
1 out of 1 hunk FAILED -- saving rejects to file docs-xml/smbdotconf/printing/printcommand.xml.rej

error: Bad exit status from /var/tmp/rpm-tmp.ulMvkp (%prep)

0000645: KVM AMD-V Random Crashes

Tue, 07 Jul 2026 01:34:38 +0000

Hello. I run many Almalinux systems with various AMD CPUs, a mix of Zen4 and Zen5. Over the years kernel patches for Zen4 bugs (which are many) have been pushed to fix stability particularly regarding virtualization platforms or nested virtualization. Over the past year or two I've still had seemingly completely random crashes for various reasons and I'm stumped. The most recent crash was on an Almalinux 10 system, kernel 6.12 (though similar crashes on mainline), with an Epyc 4464P processor.

The things that stick out in my vmcore dump in /var/crash:

[5516734.848500] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[5516734.848872] CPU: 13 UID: 107 PID: 3126435 Comm: CPU 0/KVM Kdump: loaded Not tainted 6.12.0-124.52.1.el10_1.x86_64 #1 PREEMPT(voluntary)
[5516734.849343] Hardware name: Supermicro AS -3015MR-H8TNR/H13SRD-F, BIOS 1.8 12/23/2025
[5516734.849473] RIP: 0010:srso_alias_return_thunk+0x5/0xfbef5

Attached is a full copy of the vmcore-dmesg crash from my original file (to cut out the standard/useless log)... Anyone have any idea on this? It's seemingly impossible to reproduce, and is random, and seems to be related to a previous flaw mitigation patch for AMD, and related to memory corruption or vulnerability from a guest virtual machine.

I thought about filing a kernel bug report but bugzilla is down, so hopefully someone here might have some insight. I have other AMD Zen4 EPYC systems with rare, random crashes, also related to the CPU/memory seemingly.