Arch Linux

jmj

Member

Registered: 2023-12-10

Posts: 5

ext4 corruption in kernel 6.1.64

https://lwn.net/Articles/954285/

I'm reading that there is a bug in 6.1.64 that causes ext4 corruption. I'm using the lts kernel and apparently I was using 6.1.64 for about 5 days before upgrading to 6.1.65.

Should I be sad?

Head_on_a_Stick

Member

From: London

Registered: 2014-02-20

Posts: 7,894

Website

Re: ext4 corruption in kernel 6.1.64

Should I be sad?

Not as sad as Debian bookworm users. Thank $DEITY I use btrfs...

Follow the advice here to see if any damage has been done to your files. I presume you have backups?

---

Juri divino omnia sunt communia

jmj

Member

Registered: 2023-12-10

Posts: 5

Re: ext4 corruption in kernel 6.1.64

Yea I checked my backups and my files seem fine. Why would Debian users be worse off? Arch has had 6.1.64 for longer yea?

karabaja4

Member

From: Croatia

Registered: 2008-09-14

Posts: 1,001

Website

Re: ext4 corruption in kernel 6.1.64

There's concerning lack of information about this.

As I understand this the files were corrupted when they were opened using O_DIRECT, a special operation that bypasses the kernel caches.

What are the common use cases for this kind of operation?

graysky

Wiki Maintainer

From: :wq

Registered: 2008-12-01

Posts: 10,621

Website

Re: ext4 corruption in kernel 6.1.64

There's concerning lack of information about this.

Agreed: https://lkml.org/lkml/2023/12/11/135

So 6.1.66 does NOT address this??

Last edited by graysky (2023-12-11 10:54:36)

---

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packages • Zsh and other configs

Lone_Wolf

Forum Moderator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 12,394

Re: ext4 corruption in kernel 6.1.64

To build and run the test that reveals the bug: indicates the Linux Test Project is what found the bug and can be used to check if a kernel is affected.

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building to complicated ?
Try clean chroot manager by graysky

graysky

Wiki Maintainer

From: :wq

Registered: 2008-12-01

Posts: 10,621

Website

Re: ext4 corruption in kernel 6.1.64

According to this "A subtle interaction between Iomap and EXT4 is being blamed for this possible EXT4 file-system data corruption bug that is found on the likes of Linux 6.1.64 and 6.1.55 point releases. The new Linux 6.1.66 point release already reverts the problematic commit."

Which patch in the 6.1.66 stable tree corresponds to the ext4 revert?

Last edited by graysky (2023-12-11 11:56:24)

---

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packages • Zsh and other configs

kevinf28

Member

Registered: 2014-07-20

Posts: 2

Re: ext4 corruption in kernel 6.1.64

According to this "A subtle interaction between Iomap and EXT4 is being blamed for this possible EXT4 file-system data corruption bug that is found on the likes of Linux 6.1.64 and 6.1.55 point releases. The new Linux 6.1.66 point release already reverts the problematic commit."

Which patch in the 6.1.66 stable tree corresponds to the ext4 revert?

---

the patch that fixes is "936e114a245b".. which was added to 6.1.66. think of it as a missing dependency

from the latest message, which also talks about the effects / potential sources of the corruption:
https://bugs.debian.org/cgi-bin/bugrepo … 1057843#78

--
The issue affects all kernels which have the commit 91562895f803
("ext4: properly sync file size update after O_SYNC direct IO") from
6.7-rc1 (which is present in 6.6.3, 6.5.13 and 6.1.64) but when commit
936e114a245b ("iomap: update ki_pos a little later in
iomap_dio_complete") from 6.5-rc1 is missing (which was backported to
5.15.142 and 6.1.66 additionally).

The only upstream combination where that reverse and missing commit
happened was 6.1.64 and 6.1.65.
---

still no easy way to check for which applications use O_DIRECT or which files are corrupted.

I used Find for the date range my PC was on with the affected kernel, poking around a few directories of interest, like etc,usr,var,home

touch -t 202312050000 /tmp/start
touch -t 202312102300 /tmp/stop

find /etc/ -cnewer /tmp/start ! -cnewer /tmp/stop

--- fortunately not many results on my PC ---

except for Firefox profile/cache since it was running (which does use Sync across PCs, which I hope would flag any corruption). Hard to check within it

Checking the HG source code for O_DIRECT does returns several results, eg:

mozilla-unified/third_party/rust/libc/src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs:605:pub const O_DIRECT: ::c_int = 0x4000;
and
mozilla-unified/security/sandbox/linux/SandboxFilter.cpp:1517:        static constexpr int allowed_flags = O_CLOEXEC | O_NONBLOCK | O_DIRECT;

schard

Forum Moderator

From: Hannover

Registered: 2016-05-06

Posts: 2,045

Website

Re: ext4 corruption in kernel 6.1.64

According to this "A subtle interaction between Iomap and EXT4 is being blamed for this possible EXT4 file-system data corruption bug [...]"

What they meant to say was "a terrible API nobody can maintain any longer".

---

macro_rules! yolo { { $($tokens:tt)* } => { unsafe { $($tokens)* } }; }

zpg443

Member

Registered: 2016-12-03

Posts: 279

Re: ext4 corruption in kernel 6.1.64

Does anyone have the release date for 6.1.64? Users with timeshift could then simply revert back to 6.1.63, and then they can update to today's 6.1.67, bypassing the issue, right?

EDIT: Looking through my own pacman log, 6.1.63 was installed on 23 November 2023. YMMV. Sadly, my oldest timeshift weekly backup was 28 Nov, and I prefer not reverting back to the archival backup from July.

In any case, my current kernel passed the test Lone_Wolf referenced.

Last edited by zpg443 (2023-12-12 21:07:11)

Head_on_a_Stick

Member

From: London

Registered: 2014-02-20

Posts: 7,894

Website

Re: ext4 corruption in kernel 6.1.64

Does anyone have the release date for 6.1.64?

2023-11-28: https://gitlab.archlinux.org/archlinux/ … 5df603d749

---

Juri divino omnia sunt communia