You are not logged in.
Pages: 1
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?
Offline
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?
Para todos todo, para nosotros nada
Offline
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?
Offline
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?
Offline
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
Offline
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 not flexible enough ?
Try clean chroot manager by graysky
Offline
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
Offline
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;
Offline
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".
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
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)
Offline
Does anyone have the release date for 6.1.64?
2023-11-28: https://gitlab.archlinux.org/archlinux/ … 5df603d749
Para todos todo, para nosotros nada
Offline
Pages: 1