SCST crashes with kernel Version > 6.1.91. Perhaps Changes in Lnx-Kernel 6.1.92 for XFS/iomap causing the problems?

[Mike-Speedcracker]

Hi there,

I'm using SCST for a long time - so at first thanks for this nice piece of software.

The reason for this message is, with changes in Kernel 6.1.92, I've got some trouble using SCST.
I think the reason for the kernel-dumps, which are mentioned later, are the commits (in Kernel 6.1.92):
e811fec51c66a0056459daa1ac834aea7d8d98f5, ea67e73129fceffd40b9193da93544c34d81b9c2, 54a37e5d07478358dcbf6e73b6c7e40e50a6f375, 580f40b4c956f38e83f66ebed4d81bbe4a7d82fb, 12339ec6fe4d41e69a81a13ca5e1c443fbe5bcba... and so on.

With kernel version < 6.1.91 everything is working fine.
Every kernel > 6.1.91 throws a kernel dump.

I'm using XFS as a underlaying file-system with a 32bit kernel.
SCST is using the modules
iscsi_scst
scst_vdisk
scst

I'm using the latest SCST git release (with the latest commit from 2024-08-19).

Here is the kernel-backtrace:

[Tue Aug 20 00:02:00 2024] ------------[ cut here ]------------
[Tue Aug 20 00:02:00 2024] WARNING: CPU: 5 PID: 2048 at fs/iomap/buffered-io.c:980 iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] Modules linked in: iscsi_scst(O) scst_vdisk(O) scst(O) dlm quota_v2 quota_tree autofs4 tcp_bbr sch_fq udf crc_itu_t input_leds led_class ses enclosure hid_generic wmi_bmof edac_mce_amd crc32_pclmul usbhid aesni_intel crypto_simd uas hid usb_storage rapl r8169 bnx2 i2c_piix4 mpt3sas ccp i2c_core sha1_generic k10temp pcspkr video wmi backlight
[Tue Aug 20 00:02:00 2024] CPU: 5 PID: 2048 Comm: disk042_0 Tainted: G S O 6.1.106_LFS_FILE01 #1
[Tue Aug 20 00:02:00 2024] Hardware name: To Be Filled By O.E.M. X370 Pro4/X370 Pro4, BIOS P10.08 01/22/2024
[Tue Aug 20 00:02:00 2024] EIP: iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] Code: 26 00 89 c6 89 d8 e8 4f e3 ed ff f0 ff 4b 1c 75 9c 89 d8 e8 22 0a ef ff 66 90 eb 91 8d b6 00 00 00 00 0f 0b e9 f5 fd ff ff 90 <0f> 0b e9 df fd ff ff 90 0f 0b 8b 45 ec 8b 55 f0 89 f9 39 c6 19 d1
[Tue Aug 20 00:02:00 2024] EAX: a733e000 EBX: 0007f000 ECX: fffffef2 EDX: 0000010e
[Tue Aug 20 00:02:00 2024] ESI: a733f000 EDI: 00000000 EBP: 86df3bd0 ESP: 86df3b80
[Tue Aug 20 00:02:00 2024] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010293
[Tue Aug 20 00:02:00 2024] CR0: 80050033 CR2: 37f87000 CR3: 0185a6e0 CR4: 00350ef0
[Tue Aug 20 00:02:00 2024] Call Trace:
[Tue Aug 20 00:02:00 2024] ? show_regs.cold+0x16/0x1b
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] ? __warn+0x87/0xe0
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] ? report_bug+0xe5/0x170
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? handle_bug+0x2a/0x50
[Tue Aug 20 00:02:00 2024] ? exc_invalid_op+0x1e/0x70
[Tue Aug 20 00:02:00 2024] ? handle_exception+0x101/0x101
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x3b0/0x440
[Tue Aug 20 00:02:00 2024] ? xfs_dax_write_iomap_end+0xa0/0xa0
[Tue Aug 20 00:02:00 2024] xfs_buffered_write_iomap_end+0x52/0xc0
[Tue Aug 20 00:02:00 2024] ? xfs_buffered_write_iomap_end+0xc0/0xc0
[Tue Aug 20 00:02:00 2024] iomap_iter+0xce/0x4b0
[Tue Aug 20 00:02:00 2024] ? xfs_dax_write_iomap_end+0xa0/0xa0
[Tue Aug 20 00:02:00 2024] iomap_file_buffered_write+0xa9/0x420
[Tue Aug 20 00:02:00 2024] xfs_file_buffered_write+0x9d/0x2e0
[Tue Aug 20 00:02:00 2024] xfs_file_write_iter+0xc9/0x100
[Tue Aug 20 00:02:00 2024] fileio_exec_async+0x25e/0x3a0 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] fileio_exec_write+0x2ce/0x400 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xdd/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xd7/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xd1/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xcb/0xf0
[Tue Aug 20 00:02:00 2024] vdev_do_job+0x36/0xe0 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0x8f/0xf0
[Tue Aug 20 00:02:00 2024] fileio_exec+0x1f/0x30 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] scst_do_real_exec+0x51/0x130 [scst]
[Tue Aug 20 00:02:00 2024] scst_exec_check_blocking+0xa8/0x220 [scst]
[Tue Aug 20 00:02:00 2024] scst_process_active_cmd+0x200/0x18f0 [scst]
[Tue Aug 20 00:02:00 2024] scst_cmd_thread+0x15c/0x500 [scst]
[Tue Aug 20 00:02:00 2024] ? prepare_to_wait_event+0x160/0x160
[Tue Aug 20 00:02:00 2024] kthread+0xd2/0x100
[Tue Aug 20 00:02:00 2024] ? scst_cmd_done_local+0x90/0x90 [scst]
[Tue Aug 20 00:02:00 2024] ? kthread_complete_and_exit+0x20/0x20
[Tue Aug 20 00:02:00 2024] ret_from_fork+0x1c/0x28
[Tue Aug 20 00:02:00 2024] ---[ end trace 0000000000000000 ]---
[Tue Aug 20 00:02:00 2024] ------------[ cut here ]------------
[Tue Aug 20 00:02:00 2024] WARNING: CPU: 5 PID: 2048 at fs/iomap/buffered-io.c:993 iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] Modules linked in: iscsi_scst(O) scst_vdisk(O) scst(O) dlm quota_v2 quota_tree autofs4 tcp_bbr sch_fq udf crc_itu_t input_leds led_class ses enclosure hid_generic wmi_bmof edac_mce_amd crc32_pclmul usbhid aesni_intel crypto_simd uas hid usb_storage rapl r8169 bnx2 i2c_piix4 mpt3sas ccp i2c_core sha1_generic k10temp pcspkr video wmi backlight
[Tue Aug 20 00:02:00 2024] CPU: 5 PID: 2048 Comm: disk042_0 Tainted: G S W O 6.1.106_LFS_FILE01 #1
[Tue Aug 20 00:02:00 2024] Hardware name: To Be Filled By O.E.M. X370 Pro4/X370 Pro4, BIOS P10.08 01/22/2024
[Tue Aug 20 00:02:00 2024] EIP: iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] Code: 8b 7d f0 01 c2 c1 e2 0c c7 45 d8 00 00 00 00 89 55 d4 39 d6 89 f9 83 d9 00 0f 8d 1e ff ff ff 89 75 d4 89 7d d8 e9 13 ff ff ff <0f> 0b 39 45 dc 8b 4d e4 19 d1 0f 8c b8 00 00 00 8b 45 ec 8b 7d dc
[Tue Aug 20 00:02:00 2024] EAX: a733f000 EBX: 00000000 ECX: a733f000 EDX: 00000000
[Tue Aug 20 00:02:00 2024] ESI: a733f000 EDI: 00000000 EBP: 86df3bd0 ESP: 86df3b80
[Tue Aug 20 00:02:00 2024] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010246
[Tue Aug 20 00:02:00 2024] CR0: 80050033 CR2: 37f87000 CR3: 0185a6e0 CR4: 00350ef0
[Tue Aug 20 00:02:00 2024] Call Trace:
[Tue Aug 20 00:02:00 2024] ? show_regs.cold+0x16/0x1b
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] ? __warn+0x87/0xe0
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] ? report_bug+0xe5/0x170
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? handle_bug+0x2a/0x50
[Tue Aug 20 00:02:00 2024] ? exc_invalid_op+0x1e/0x70
[Tue Aug 20 00:02:00 2024] ? handle_exception+0x101/0x101
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] ? exc_overflow+0x60/0x60
[Tue Aug 20 00:02:00 2024] ? iomap_file_buffered_write_punch_delalloc+0x2f0/0x440
[Tue Aug 20 00:02:00 2024] ? xfs_dax_write_iomap_end+0xa0/0xa0
[Tue Aug 20 00:02:00 2024] xfs_buffered_write_iomap_end+0x52/0xc0
[Tue Aug 20 00:02:00 2024] ? xfs_buffered_write_iomap_end+0xc0/0xc0
[Tue Aug 20 00:02:00 2024] iomap_iter+0xce/0x4b0
[Tue Aug 20 00:02:00 2024] ? xfs_dax_write_iomap_end+0xa0/0xa0
[Tue Aug 20 00:02:00 2024] iomap_file_buffered_write+0xa9/0x420
[Tue Aug 20 00:02:00 2024] xfs_file_buffered_write+0x9d/0x2e0
[Tue Aug 20 00:02:00 2024] xfs_file_write_iter+0xc9/0x100
[Tue Aug 20 00:02:00 2024] fileio_exec_async+0x25e/0x3a0 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] fileio_exec_write+0x2ce/0x400 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xdd/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xd7/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xd1/0xf0
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0xcb/0xf0
[Tue Aug 20 00:02:00 2024] vdev_do_job+0x36/0xe0 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] ? __switch_to_asm+0x8f/0xf0
[Tue Aug 20 00:02:00 2024] fileio_exec+0x1f/0x30 [scst_vdisk]
[Tue Aug 20 00:02:00 2024] scst_do_real_exec+0x51/0x130 [scst]
[Tue Aug 20 00:02:00 2024] scst_exec_check_blocking+0xa8/0x220 [scst]
[Tue Aug 20 00:02:00 2024] scst_process_active_cmd+0x200/0x18f0 [scst]
[Tue Aug 20 00:02:00 2024] scst_cmd_thread+0x15c/0x500 [scst]
[Tue Aug 20 00:02:00 2024] ? prepare_to_wait_event+0x160/0x160
[Tue Aug 20 00:02:00 2024] kthread+0xd2/0x100
[Tue Aug 20 00:02:00 2024] ? scst_cmd_done_local+0x90/0x90 [scst]
[Tue Aug 20 00:02:00 2024] ? kthread_complete_and_exit+0x20/0x20
[Tue Aug 20 00:02:00 2024] ret_from_fork+0x1c/0x28
[Tue Aug 20 00:02:00 2024] ---[ end trace 0000000000000000 ]---

Now my question is:
Where we have to search for the problem? At the kernel- or at SCST source code?

Thanks in advance and for further investigation,
Mike

[Mike-Speedcracker]

Addendum:

I asked ChatGPT what the cause could be by looking at the kernel 6.1.91 and 6.1.92 changelogs.
Here is the answer...

---

After comparing the changelogs for Kernel 6.1.91 and 6.1.92, I noticed several XFS-related changes in 6.1.92, particularly around Copy-on-Write (CoW) and buffer management. These updates could be the root cause of your issue, especially since your setup uses SCST, which interacts with the filesystem. The changes in buffer invalidation handling during CoW operations may be causing conflicts with SCST's I/O operations, leading to the backtrace.

Testing different I/O patterns or temporarily reverting these changes might help narrow down the issue further.

Perhaps it is interesting? :)

Regards,
Mike

[dodexahedron]

Are you using file-backed devices? If not, I can't imagine that XFS would have anything to do with an SCST problem, unless you mean you're using XFS on the mounted LUNs. But in that case, it shouldn't be related to SCST anyway, because the initiator just sees a block device with whatever attributes it was configured with. So I think XFS is a red herring here, if not using file-backed devices.

When we were still using 6.1 kernels through 6.4 kernels, we did encounter occasional issues with SCST (and also ZFS), but they were sporadic and difficult to duplicate, and seemed to only really happen under high load.

May I ask why 6.1.92 is being used, as an upgrade, especially? 6.1.115 is the latest and final release of 6.1 (outside of critical security patches only), and is itself almost 2 years old. Even RHEL 8, which is already past its main support phase, uses the next LTS kernel beyond that, which is 6.6. Is at least testing with 6.6 feasible for your system? As for Ubuntu, which we also have, the only currently supported Ubuntu releases with a 6.x kernel are 24.04 and later, which are on 6.8 at minimum out of the box.

For what it's worth, CentOS and RHEL 8 boxes we have, on a range of kernels from 6.6 (the base included kernel with RHEL 8.10) to 6.11 mainline kernels, as well as Ubuntu 24.04.01 systems on a mix of 6.8 (stock) and 6.11 (xanmod) kernels, all compile and run SCST without issue, including lab instances that have XFS, ZFS, BTRFS, and EXT4 with file-backed SCST devices on them all, specifically for testing.

[Mike-Speedcracker]

Hi there,

at first: Thanks for answering.

Here are my answers to your questions:

Are you using file-backed devices? If not, I can't imagine that XFS would have anything to do with an SCST problem, unless you mean you're using XFS on the mounted LUNs. But in that case, it shouldn't be related to SCST anyway, because the initiator just sees a block device with whatever attributes it was configured with. So I think XFS is a red herring here, if not using file-backed devices.

Yes, I'm using file-backed devices, if you mean using vdisk_fileio.
A file will be exported by vdisk_fileio as a lun through SCST target, which exists on an XFS formatted device (logical volume).
The initiator is an ESXi Server (Version 7.3).

When we were still using 6.1 kernels through 6.4 kernels, we did encounter occasional issues with SCST (and also ZFS), but they were sporadic and difficult to duplicate, and seemed to only really happen under high load._

By using kernel 6.1.91 or lower version, no problems occur.
By using kernel 6.1.92 or up (latest tests I've done with 6.1.105 - then I gave up) and high I/O workload, the problem occur.

May I ask why 6.1.92 is being used, as an upgrade, especially? 6.1.115 is the latest and final release of 6.1 (outside of critical security patches only), and is itself almost 2 years old. Even RHEL 8, which is already past its main support phase, uses the next LTS kernel beyond that, which is 6.6. Is at least testing with 6.6 feasible for your system? As for Ubuntu, which we also have, the only currently supported Ubuntu releases with a 6.x kernel are 24.04 and later, which are on 6.8 at minimum out of the box._

I'm using an own created Linux-box, without using mainstream Linux distributions.
So I stayed a long time at the LTS kernel version 4.19.x, but the support will end December 2024, so I have to go further and changed everything for using kernel version 6.1.x.
Don't ask me why I haven't used kernel 6.6 so far.
6.1 will be supported till December 2026 like 6.6, so I thought: Don't use the newest stuff to get it stable running?
:)
Many changes were made to XFS in kernel 6.1.92, which may lead to the problem.
But I'm not a coder, so I'll first look for the trigger here and maybe open a ticket in kernel bug tracking.

For what it's worth, CentOS and RHEL 8 boxes we have, on a range of kernels from 6.6 (the base included kernel with RHEL 8.10) to 6.11 mainline kernels, as well as Ubuntu 24.04.01 systems on a mix of 6.8 (stock) and 6.11 (xanmod) kernels, all compile and run SCST without issue, including lab instances that have XFS, ZFS, BTRFS, and EXT4 with file-backed SCST devices on them all, specifically for testing._

My experience is, that the newest kernel is not always the best. So I choose a kernel tree, which is not the newest, with LTS support that lasts till end of 2026, with the hope, that this kernel tree is more stable.

[dodexahedron]

Yes, I'm using file-backed devices, if you mean using vdisk_fileio. A file will be exported by vdisk_fileio as a lun through SCST target, which exists on an XFS formatted device (logical volume). The initiator is an ESXi Server (Version 7.3).

Gotcha. Yep, that's what I was referring to.

Something you may find helpful to consider is using GPT partitions or LVM (which also enables thin provisioning capabilities) so that you can target block devices with vdisk_blockio, rather than files, removing the XFS layer from the picture. Migration to that is pretty easy, as you can just dd your file to the block device for a partition and you now have a bit-for-bit clone ready to use. It's one less thing to be able to go wrong, and less chance of data corruption/loss in the event of an unexpected shutdown, kernel panic, hung SCST thread, aborts, etc. Also, it is likely to help avoid unnecessary write amplification that can be caused by having a file system on a virtual block device backed by a file on a file system on a real block device, which is a performance and longevity improvement all on its own. And so long as you ensure the various identifiers are the same on the new blockio devices as they were on the fileio devices, the initiators won't know anything changed. You can get a full configuration to help you ensure you don't miss something by doing a scstadmin -nonkey -write_config somefile.conf to get all the other properties SCST has that are automatically generated. Just copy them all to the block devices and you're good to go. Don't export LUNs with the same IDs to the same initiators, though, even on different LUNs, as that can lead to all sorts of pain.

By using kernel 6.1.91 or lower version, no problems occur. By using kernel 6.1.92 or up (latest tests I've done with 6.1.105 - then I gave up) and high I/O workload, the problem occur.

Yeah, fun things can crop up under load, especially as the number of involved components goes up. And the type of activity matters, too. Like if you have frequent TRIM/UNMAP activity, that can slow the entire works down, especially if you have SATA drives, since many of those force a full synchronous buffer flush upon receipt of a TRIM.

We used to have files on top of XFS like you, as well, but moved to block devices a long time ago (those being zvols in ZFS nowadays), and so many of the random little issues we kept having in our storage setup disappeared. I can't give specific commentary on that kernel version as I'm not using it anywhere. I definitely wouldn't rule out kernel changes in the XFS module being responsible for at least part of the problem, of course, since that indeed is relevant for your setup.

I'm using an own created Linux-box, without using mainstream Linux distributions. So I stayed a long time at the LTS kernel version 4.19.x, but the support will end December 2024, so I have to go further and changed everything for using kernel version 6.1.x. Don't ask me why I haven't used kernel 6.6 so far. 6.1 will be supported till December 2026 like 6.6, so I thought: Don't use the newest stuff to get it stable running? :) Many changes were made to XFS in kernel 6.1.92, which may lead to the problem. But I'm not a coder, so I'll first look for the trigger here and maybe open a ticket in kernel bug tracking.

My experience is, that the newest kernel is not always the best. So I choose a kernel tree, which is not the newest, with LTS support that lasts till end of 2026, with the hope, that this kernel tree is more stable.

Fair enough. Anecdotally, across dozens of personal and work machines, the modern kernels haven't had trouble with SCST specifically in our environment, across a wide range of hardware, and some under quite heavy load (e.g. some that are never below 20k IOPs on some LUNs) but what works for you is what works for you. Yay FOSS! 😊 Just relating my experience for your consideration. Do you build the kernels yourself? If not, it may be worth a shot at least testing a 6.6 or later just to see if the problem goes away for you (if you stick with file-backed devices, that is). If it does, then you could bisect to figure out where it gets better so you can use that or at least have a road map for yourself. I mean there's no reason you couldn't if you do build it yourself, but that's probably not the kind of additional work I imagine is at the top of your wish list to do. 😅

As for a bug report on 6.1:
Doesn't hurt to try, though I'm not sure how eager kernel maintainers will be to investigate that one, if it is already fixed in later kernels and wasn't deemed worthwhile or feasible to back-port to earlier supported kernels. There was a 6.1.115 release recently, with a bunch of fixes, but I didn't see any related to XFS in the commit log. I didn't look through the logs between 92 and 115 though to see if there are any, but here's you a direct link to the 6.1.y branch commit log on kernel.org for your convenience: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.1.y

Note that it is entirely possible for changes not necessarily directly related to XFS to have an impact on it, regardless, so the fact that I didn't see anything mentioning XFS in the 115 and 114 commit logs isn't necessarily an authoritative indication of what your results may end up being.

In any case, definitely don't take it as me version-shaming you haha. Just wanted a better picture so I could provide you with the best thoughts I can.

I think your assessment that XFS and changes within the kernel affecting it are likely at the heart of your problem is pretty likely correct. So, even without the other file vs block considerations above, I'd still probably lean toward migrating to block devices, were I in your shoes and if specific kernel branch is an important priority above others.

Oh, another thought: You could try testing it out on a VM for some easier and non-destructive investigation, if you haven't already considered that. 🤷‍♂️

[Mike-Speedcracker]

Hey, sorry for the late reply — I got blocked on GIT for some strange reason.
It took months to get it sorted out because support kept bouncing the ticket around.

Now that my account's finally active again, I just wanted to jump back into this thread.

Thanks a lot for the analysis and the info you shared — super helpful!
With that, I was able to file a proper ticket on bugzilla.kernel.org.
And yep, it actually turned out to be a bug in the 32-bit branch of the kernel.

For completeness, here are the links to the patches (Bug 219504):

https://lore.kernel.org/linux-xfs/20250102190540.1356838-1-marco.nelissen@xxxxxxxxx/
https://lore.kernel.org/linux-xfs/20250109041253.2494374-1-marco.nelissen@xxxxxxxxx/

Thanks again for your help and the detailed analysis.

Regads,
Mike

[dodexahedron]

Oh cool. Thanks for the follow-up!

FYI: Github or something anonymized and broke your links to the thread, due to the email address.

For anyone stumbling across this who gets curious, here are the direct links to the commits in git.kernel.org:

https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/mm/filemap.c?id=f505e6c91e7a22d10316665a86d79f84d9f0ba76

https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/fs/iomap/buffered-io.c?id=c13094b894de289514d84b8db56d1f2931a0bade

Note that, at this time (2025-06-07), these are not yet merged to master, but they have been merged into the 6.15 RC branches, so the fixes should be coming in kernel version 6.15.