linux-ext4 - [Bug 218006] [ext4] system panic when ext4_writepages:2918: Journal has aborted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bug-218006-13602-sySzU4Xe1v@https.bugzilla.kernel.org/>
Date:   Tue, 17 Oct 2023 01:41:21 +0000
From:   bugzilla-daemon@...nel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 218006] [ext4] system panic when ext4_writepages:2918: Journal
 has aborted

https://bugzilla.kernel.org/show_bug.cgi?id=218006

--- Comment #7 from Gary (fengchunguo@....com) ---
(In reply to Theodore Tso from comment #6)
> Unfortunately the 4.14 kernel was released in 2017, which is over six years
> ago.   Most companies where you can pay $$$ to get support for Linux
> distributions based on 4.14 are EOL'ing products based on 4.14.   As far
> upstream kernel developers who are essentially volunteers when people ask
> them for free help, in general, upstream kernel developers do not support
> LTS kernels, and certainly not an LTS kernel as old as 4.14.
> 
> If there is someone is willing to be the ext4 upstream stable backports
> maintainer, then that person might be willing to provide limited support for
> LTS kernels --- but the 4.14 LTS upstream kernel is planned to be EOL'ed in
> January 2024, and I had stopped running gce-xfstests on 4.14 LTS kernels
> about a year or so ago.  I barely have time to run gce-xfststs on LTS
> kernels for 6.1, 5.15 and 5.10 every quarter or two, and if someone were to
> volunteer to become ext4 stable backports maintainer, I'd encourage them to
> focus on 6.6 and 6.1 LTS kernels, with 5.10 and 5.15 LTS kernels as a lower
> priority (because most commercial companies are going to be moving off of
> 5.10 LTS in the near future).   But volunteer support for 4.14 LTS?  TO be
> honest, that's extremely unlikely.
> 
> *If* there is a company that has a misguided business reason to support the
> 4.14 LTS kernel, then of course an employee of that company can certainly
> fund an engineer to to do all of the support that they need.  But quite
> frankly, I'd be encouraging that company to rethink their business case for
> supporting the 4.14 kernel.   It would be probably far more cost effective
> to migrate their customers to a non-pre-historic kernel such as the 6.6 LTS
> kernel.

Thanks for your reply.

We will try to debug this issue. For this issue, I think that we should focus
on the below infromation. Emmc error should be one side effect.

[2023-10-13 02:51:08]  [60086.731357] EXT4-fs error (device mmcblk0p44) in
ext4_da_write_end:3210: IO failure
[2023-10-13 02:51:09]  [60086.739386] EXT4-fs (mmcblk0p44): Delayed block
allocation failed for inode 155757 at logical offset 438 with max blocks 25
with error 30
[2023-10-13 02:51:09]  [60086.739388] EXT4-fs (mmcblk0p44): This should not
happen!! Data will be lost
[2023-10-13 02:51:09]  [60086.739388]
[2023-10-13 02:51:09]  [60086.739399] EXT4-fs error (device mmcblk0p44) in
ext4_writepages:2918: Journal has aborted

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.