[regression] linux: Loop-mounted UDF ISOs no longer readable

[regression] linux: Loop-mounted UDF ISOs no longer readable

[Salvatore Bonaccorso]

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:

> 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?

#regzbot introduced: v6.1.112..v6.1.115
#regzbot monitor: https://bugs.debian.org/1089698

Regards,
Salvatore

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Zhao Mengmeng]

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

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Zhao Mengmeng]

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@suse.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@suse.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.

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Greg KH]

On Tue, Dec 24, 2024 at 05:46:59PM +0800, Zhao Mengmeng wrote:
> 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@suse.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@suse.cz>

It's already queued up for the next 6.1.y release in a few days, so if
you could test the -rc that is out for review right now, that would be
great!

thanks,

greg k-h

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Daniel Reichelt]

Hi Zhao,

> commit 1ea1cd11c72d1405a6b98440a9d5ea82dfa07166
> Author: Jan Kara <jack@suse.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@suse.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.

I just tested v6.1.120 +1ea1cd11c72d1405a6b98440a9d5ea82dfa07166 and I 
can confirm that at least `ls $mntpt/sources` gives viable output. 
However, actually running windows setup off a samba share from such a 
$mntpt gives data errors at the very end of windows setup. I guess 
something else is missing...


Thanks!

Daniel

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Daniel Reichelt]

Hello again,

On 24.12.24 15:21, Daniel Reichelt wrote:
> I just tested v6.1.120 +1ea1cd11c72d1405a6b98440a9d5ea82dfa07166 and I 
> can confirm that at least `ls $mntpt/sources` gives viable output. 
> However, actually running windows setup off a samba share from such a 
> $mntpt gives data errors at the very end of windows setup. I guess 
> something else is missing...

I just re-ran that test on the actual server network instead of my 
laptop and there everything worked fine. I found some SIGSEGVs in the 
Samba log on my laptop from the earlier test so the "data errors" were a 
completely different issue caused by smbd.

So all in all, I'd say the UDF issue is fixed by the cherry-pick. Sorry 
for the noise.

Cheers
Daniel

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Zhao Mengmeng]

On 2024/12/24 17:59, Greg KH wrote:
> On Tue, Dec 24, 2024 at 05:46:59PM +0800, Zhao Mengmeng wrote:
>> 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@suse.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@suse.cz>
> 
> It's already queued up for the next 6.1.y release in a few days, so if
> you could test the -rc that is out for review right now, that would be
> great!

Glad to test it, will do.

> thanks,
> 
> greg k-h

Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Zhao Mengmeng]

On 2024/12/25 05:21, Daniel Reichelt wrote:
> Hello again,
> 
> On 24.12.24 15:21, Daniel Reichelt wrote:
>> I just tested v6.1.120 +1ea1cd11c72d1405a6b98440a9d5ea82dfa07166 and I can confirm that at least `ls $mntpt/sources` gives viable output. However, actually running windows setup off a samba share from such a $mntpt gives data errors at the very end of windows setup. I guess something else is missing...
> 
> I just re-ran that test on the actual server network instead of my laptop and there everything worked fine. I found some SIGSEGVs in the Samba log on my laptop from the earlier test so the "data errors" were a completely different issue caused by smbd.
> 
> So all in all, I'd say the UDF issue is fixed by the cherry-pick. Sorry for the noise.
> 
> Cheers
> Daniel

That's great, thanks.