Message-ID: <6c8e6c68-b0a1-47b4-82a4-c68490fdc876@kylinos.cn>
Date: Tue, 24 Dec 2024 17:46:59 +0800
From: Zhao Mengmeng <zhaomengmeng@...inos.cn>
To: Jan Kara <jack@...e.cz>, sashal@...nel.org,
 Salvatore Bonaccorso <carnil@...ian.org>,
 Daniel Reichelt <debian@...htgeist.net>
Cc: linux-kernel@...r.kernel.org, 1089698@...s.debian.org,
 regressions@...ts.linux.dev
Subject: Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

On 2024/12/23 10:48, Zhao Mengmeng wrote:
> On 2024/12/21 03:49, Salvatore Bonaccorso wrote:
>> Hi Jan, hi Zhao,
>>
>> In Debian we got he following report, full quoted below from Daniel
>> Reichelt, dass after updating to 6.1.115 (and later, confirmed up to
>> 6.1.119), loop-mounted UDF ISOs are no longer readable:
> 
> Sorry to hear that...
> 
>>> Hi,
>>>
>>> in 6.1.112-1 I could loop-mount Windows Setup ISOs (downloaded from M$; hashes
>>> are fine; 10/11, DE/EN don't seem to make any difference) and access their
>>> content perfectly fine, i.e. share the /sources/ sub-directory via samba for
>>> netinstall scenarios.
>>>
>>> Starting with 6.1.115-1, the ISOs can be mounted, the root-dir is accessible
>>> and `stat $mntpt/sources` gives output as well. However `ls $mntpt/sources`
>>> hangs and the kernel log is spammed with entries like
>>>
>>> ---------------8<-------------------------
>>> 2024-12-11T14:53:19.616728+01:00 srv kernel: [182394.024828] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.629970+01:00 srv kernel: [182394.038041] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.641623+01:00 srv kernel: [182394.049714] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.654841+01:00 srv kernel: [182394.062928] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.666495+01:00 srv kernel: [182394.074615] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.679747+01:00 srv kernel: [182394.087833] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.691394+01:00 srv kernel: [182394.099510] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.704646+01:00 srv kernel: [182394.112727] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.716283+01:00 srv kernel: [182394.124400] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.729539+01:00 srv kernel: [182394.137618] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.741185+01:00 srv kernel: [182394.149279] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.754422+01:00 srv kernel: [182394.162494] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> 2024-12-11T14:53:19.766071+01:00 srv kernel: [182394.174159] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>>> 2024-12-11T14:53:19.779289+01:00 srv kernel: [182394.187375] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>>> ---------------8<-------------------------
>>>
>>>
>>> 6.1.119-1 shows the same behaviour.
>>> Let me know if you need additional info.
>>
>> We have not a full bisect, but Daniel confirmed already in
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089698#22 some
>> observations:
>>
>>> OK:
>>>   6.1.112-1
>>> BAD:
>>>   6.1.115-1
>>>   6.1.119-1
>>> OK again:
>>>   6.3.1-1~exp1
>>>   current trixie
>>>   current sid
>>
>> (current trixie is 6.11.10 based kernel, current sid is based on
>> 6.12.5 kernel).
>>
>> Dies this ring some bell to you?
> 
> I'll take a look at it. Will post it here if anything new founded.
> 
>> #regzbot introduced: v6.1.112..v6.1.115
>> #regzbot monitor: https://bugs.debian.org/1089698
>>
>> Regards,
>> Salvatore
> 
--------------------
Update on 2024.12.24:

Hi Jan, Sasha, after some testing and code digging, I found that v6.1 LTS may need 
this patch to solve Daniel's issue:

commit 1ea1cd11c72d1405a6b98440a9d5ea82dfa07166
Author: Jan Kara <jack@...e.cz>
Date:   Wed Jan 25 11:43:03 2023 +0100

    udf: Fix directory iteration for longer tail extents
    
    When directory's last extent has more that one block and its length is
    not multiple of a block side, the code wrongly decided to move to the
    next extent instead of processing the last partial block. This led to
    directory corruption. Fix the rounding issue.
    
    Signed-off-by: Jan Kara <jack@...e.cz>

diff --git a/fs/udf/directory.c b/fs/udf/directory.c
index b1424e2aa868..31f1bf8ab848 100644
--- a/fs/udf/directory.c
+++ b/fs/udf/directory.c
@@ -170,7 +170,7 @@ static struct buffer_head *udf_fiiter_bread_blk(struct udf_fileident_iter *iter)
 static int udf_fiiter_advance_blk(struct udf_fileident_iter *iter)
 {
        iter->loffset++;
-       if (iter->loffset < iter->elen >> iter->dir->i_blkbits)
+       if (iter->loffset < DIV_ROUND_UP(iter->elen, 1<<iter->dir->i_blkbits))
                return 0;
 
        iter->loffset = 0;


In my qemu environment, with v6.1.115 plus this patch, `ls $mntpt/sources` will
work as normal. 

Jan, I'm not very familiar with this patchset, maybe some more patches needs to
be backported to solve this problem? I'd love to hear from you.

Deniel, if it possible, could you cherry-pick this patch to your kernel source 
as a temporary workaround, and test if it really fix your problem? Thanks.
  
--------------------
Update on 2024.12.23:

Hi Jan, I have tested v6.1 upstream kernel with x86_64_defconfig, it turns out:

v6.1.112 is good as Daniel reported,
v6.1.114 is bad, but the log is little different.
                                              
[   21.307158] UDF-fs: error (device sr0): udf_fiiter_advance_blk: extent after position 12280 not allocated in directory (ino 312)                                                           
[   21.307832] UDF-fs: error (device sr0): udf_verify_fi: directory (ino 312) has entry where CRC length (2) does not match entry length (24)                                                 
[   21.308738] UDF-fs: error (device sr0): udf_fiiter_advance_blk: extent after position 12280 not allocated in directory (ino 312)                                                           
[   21.309785] UDF-fs: error (device sr0): udf_verify_fi: directory (ino 312) has entry where CRC length (2) does not match entry length (24)                                                 
[   21.310996] UDF-fs: error (device sr0): udf_fiiter_advance_blk: extent after position 12280 not allocated in directory (ino 312)          

I also manually revert my patch "udf: refactor udf_current_aext() to handle error" based on v6.1.115, and
it's still broken, looks like something wrong in v6.1.114.

Powered by blists - more mailing lists