Bug 216317 - "ext4: lblock 0 mapped to illegal pblock" after upgrading to 5.19.0
Summary: "ext4: lblock 0 mapped to illegal pblock" after upgrading to 5.19.0
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P1 high
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-02 05:49 UTC by David Korth
Modified: 2022-08-17 14:59 UTC (History)
0 users

See Also:
Kernel Version: 5.19.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description David Korth 2022-08-02 05:49:49 UTC
On upgrading to kernel 5.19.0, I hit a bunch of warnings and inaccessible files. Attempting to access e.g. /etc/alsa/conf.d/51-pulseaudio-probe.conf (symlink to ../../../usr/share/alsa/alsa.conf.d/51-pulseaudio-probe.conf) resulted in a "Structure needs cleaning" error. Checking dmesg shows the following:

Aug 02 01:10:43 [kernel] [   12.037708] EXT4-fs error (device dm-2): ext4_map_blocks:599: inode #14680223: block 774843950: comm alsactl: lblock 0 mapped to illegal pblock 774843950 (length 1)
Aug 02 01:10:43 [kernel] [   12.039070] EXT4-fs error (device dm-2): ext4_map_blocks:599: inode #14680223: block 774843950: comm alsactl: lblock 0 mapped to illegal pblock 774843950 (length 1)
Aug 02 01:10:43 [kernel] [   12.041453] EXT4-fs error (device dm-2): ext4_map_blocks:599: inode #14680223: block 774843950: comm alsactl: lblock 0 mapped to illegal pblock 774843950 (length 1)
Aug 02 01:10:43 [kernel] [   12.043086] EXT4-fs error (device dm-2): ext4_map_blocks:599: inode #14680223: block 774843950: comm alsactl: lblock 0 mapped to illegal pblock 774843950 (length 1)
Aug 02 01:10:43 [kernel] [   12.045207] EXT4-fs error (device dm-2): ext4_map_blocks:599: inode #14680223: block 774843950: comm alsactl: lblock 0 mapped to illegal pblock 774843950 (length 1)

Lots of other files were also showing the same issue. Reverting to 5.18.10 (and running fsck) fixed it with no noticeable corruption.

Rootfs is ext4, using LVM-on-LUKS. (/dev/sda2 is a LUKS volume that contains an LVM physical volume.) I have inline data turned on; the symlink is 60 bytes, so it could be an inline data issue, but other symlinks in /etc/alsa/conf.d/ weren't showing the problem.
Comment 1 David Korth 2022-08-02 05:50:30 UTC
Distribution is Gentoo Linux amd64, 17.1 hardened profile.
Comment 2 David Korth 2022-08-02 05:58:17 UTC
After doing some searching, it looks like this commit may fix the issue:

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=f50f5a5eac8092fb9b3365ca4b1d7407cdab8427

ext4: fix reading leftover inlined symlinks
Since commit 6493792d3299 ("ext4: convert symlink external data block
mapping to bdev"), create new symlink with inline_data is not supported,
but it missing to handle the leftover inlined symlinks, which could
cause below error message and fail to read symlink.

 ls: cannot read symbolic link 'foo': Structure needs cleaning

 EXT4-fs error (device sda): ext4_map_blocks:605: inode #12: block
 2021161080: comm ls: lblock 0 mapped to illegal pblock 2021161080
 (length 1)

Fix this regression by adding ext4_read_inline_link(), which read the
inline data directly and convert it through a kmalloced buffer.
Comment 3 David Korth 2022-08-02 06:14:12 UTC
Reading the various commits, it seems that ext4's inline_data option previously supported inlining symlinks, but as of v5.19.0, that's no longer supported. The patch restores read-only compatibility, but new symlinks will not be inlined. Is there any particular reason why symlink inlining was removed, and/or does the new method work better than inlining?
Comment 4 Artem S. Tashkinov 2022-08-17 14:59:22 UTC
This must be fixed in just released 5.19.2.

Note You need to log in before you can comment on or make changes to this bug.