* [regression] linux: Loop-mounted UDF ISOs no longer readable @ 2024-12-20 19:49 Salvatore Bonaccorso 2024-12-23 2:48 ` Zhao Mengmeng 0 siblings, 1 reply; 8+ messages in thread From: Salvatore Bonaccorso @ 2024-12-20 19:49 UTC (permalink / raw) To: regressions, Zhao Mengmeng, Jan Kara; +Cc: Daniel Reichelt, linux-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-20 19:49 [regression] linux: Loop-mounted UDF ISOs no longer readable Salvatore Bonaccorso @ 2024-12-23 2:48 ` Zhao Mengmeng 2024-12-24 9:46 ` Zhao Mengmeng 0 siblings, 1 reply; 8+ messages in thread From: Zhao Mengmeng @ 2024-12-23 2:48 UTC (permalink / raw) To: Salvatore Bonaccorso, regressions, Jan Kara; +Cc: Daniel Reichelt, linux-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-23 2:48 ` Zhao Mengmeng @ 2024-12-24 9:46 ` Zhao Mengmeng 2024-12-24 9:59 ` Greg KH 2024-12-24 14:21 ` Daniel Reichelt 0 siblings, 2 replies; 8+ messages in thread From: Zhao Mengmeng @ 2024-12-24 9:46 UTC (permalink / raw) To: Jan Kara, sashal, Salvatore Bonaccorso, Daniel Reichelt Cc: linux-kernel, 1089698, regressions 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. ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-24 9:46 ` Zhao Mengmeng @ 2024-12-24 9:59 ` Greg KH 2024-12-25 1:06 ` Zhao Mengmeng 2024-12-24 14:21 ` Daniel Reichelt 1 sibling, 1 reply; 8+ messages in thread From: Greg KH @ 2024-12-24 9:59 UTC (permalink / raw) To: Zhao Mengmeng Cc: Jan Kara, sashal, Salvatore Bonaccorso, Daniel Reichelt, linux-kernel, 1089698, regressions 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-24 9:59 ` Greg KH @ 2024-12-25 1:06 ` Zhao Mengmeng 0 siblings, 0 replies; 8+ messages in thread From: Zhao Mengmeng @ 2024-12-25 1:06 UTC (permalink / raw) To: Greg KH Cc: Jan Kara, sashal, Salvatore Bonaccorso, Daniel Reichelt, linux-kernel, 1089698, regressions 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-24 9:46 ` Zhao Mengmeng 2024-12-24 9:59 ` Greg KH @ 2024-12-24 14:21 ` Daniel Reichelt 2024-12-24 21:21 ` Daniel Reichelt 1 sibling, 1 reply; 8+ messages in thread From: Daniel Reichelt @ 2024-12-24 14:21 UTC (permalink / raw) To: Zhao Mengmeng, Jan Kara, sashal, Salvatore Bonaccorso Cc: linux-kernel, 1089698, regressions 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-24 14:21 ` Daniel Reichelt @ 2024-12-24 21:21 ` Daniel Reichelt 2024-12-25 1:07 ` Zhao Mengmeng 0 siblings, 1 reply; 8+ messages in thread From: Daniel Reichelt @ 2024-12-24 21:21 UTC (permalink / raw) To: Zhao Mengmeng, Jan Kara, sashal, Salvatore Bonaccorso Cc: linux-kernel, 1089698, regressions 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [regression] linux: Loop-mounted UDF ISOs no longer readable 2024-12-24 21:21 ` Daniel Reichelt @ 2024-12-25 1:07 ` Zhao Mengmeng 0 siblings, 0 replies; 8+ messages in thread From: Zhao Mengmeng @ 2024-12-25 1:07 UTC (permalink / raw) To: Daniel Reichelt, Jan Kara, sashal, Salvatore Bonaccorso Cc: linux-kernel, 1089698, regressions 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-12-25 1:07 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-12-20 19:49 [regression] linux: Loop-mounted UDF ISOs no longer readable Salvatore Bonaccorso 2024-12-23 2:48 ` Zhao Mengmeng 2024-12-24 9:46 ` Zhao Mengmeng 2024-12-24 9:59 ` Greg KH 2024-12-25 1:06 ` Zhao Mengmeng 2024-12-24 14:21 ` Daniel Reichelt 2024-12-24 21:21 ` Daniel Reichelt 2024-12-25 1:07 ` Zhao Mengmeng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.