Re: Are there still machines with PAGE_SHIFT 16 or larger ?
On Wed, Nov 11, 2020 at 11:09 PM Thomas Schmitt <scdbackup@gmx.net> wrote:
>
> Hi,
>
> after some confusion i found out that the endianness bug was fixed
> unnoticed a few weeks ago, when i implemented zisofs version 2. The
> current GNU xorriso development tarball has it already fixed.
> https://www.gnu.org/software/xorriso/xorriso-1.5.3.tar.gz
>
>
> Anatoly Pugachev wrote:
> > copied (freshly generated) test.iso from x86_64 VM to ppc64 host:
> > [...]
> > works.
>
> In the light of my kernel code inspection it might be that the test
> file was too redundant and hides a problem.
> The other problem i see needs aligned 32 KiB chunks of zeros.
>
> This file should be compressible and sensitive to smaller glitches:
>
> dd if=/dev/urandom bs=1K count=161 | od -t x1 | \
> sed -e 's/^[0-7]* //' -e 's/ //g' -e 's/.$//' | head -n -1 \
> >/tmp/full_random
>
> Result:
> -rw-r--r-- 1 thomas thomas 329728 Nov 11 20:49 /tmp/full_random
>
> This file consists by half of aligned 32 KiB zero blocks:
>
> for i in {0..1}
> do
> dd if=/dev/urandom bs=1K count=16 | od -t x1 | \
> sed -e 's/^[0-7]* //' -e 's/ //g' -e 's/.$//' | head -n -1
> dd if=/dev/zero bs=64K count=1
> dd if=/dev/urandom bs=1K count=16 | od -t x1 | \
> sed -e 's/^[0-7]* //' -e 's/ //g' -e 's/.$//' | head -n -1
> done 2>/dev/null >/tmp/half_sparse
>
> Result:
> -rw-r--r-- 1 thomas thomas 262144 Nov 11 20:49 /tmp/half_sparse
>
> On a little-endian machine or with xorriso-1.5.3 pack up test2.iso:
>
> xorriso -outdev /tmp/test2.iso \
> -map /tmp/half_sparse /half_sparse \
> -map /tmp/full_random /full_random \
> -zisofs block_size=32k \
> -set_filter_r --zisofs / -- \
> -padding 0 -compliance no_emul_toc
>
> According to the higher information content the ISO is larger:
> -rw-r--r-- 1 thomas thomas 339968 Nov 11 20:50 /tmp/test2.iso
>
> On PAGE_SIZE <= 32 KiB i expect the MD5 sums to match:
>
> md5sum /tmp/half_sparse /mnt/iso/half_sparse
>
> md5sum /tmp/full_random /mnt/iso/full_random
>
> At least "half_sparse" should come out wrong on PAGE_SIZE >= 64 KiB.
Created tmp test files and /tmp/test2.iso on a little endian x86_64 VM
, then copied tmp and iso files to ppc64 host (chubaka).
Results are :
root@chubaka:/home/mator# mount test2.iso -o ro,loop /mnt/iso
mator@chubaka:~$ md5sum /tmp/full_random /mnt/iso/full_random
9014e927951d25e01aa89858ebb82ce6 /tmp/full_random
9014e927951d25e01aa89858ebb82ce6 /mnt/iso/full_random
mator@chubaka:~$ md5sum /tmp/half_sparse /mnt/iso/half_sparse
3e98c342558c453b379cf7699f98a108 /tmp/half_sparse
Segmentation fault
mator@chubaka:~$ ls -lh /mnt/iso
total 266K
-rw-r--r-- 1 mator users 322K Nov 12 19:25 full_random
-rw-r--r-- 1 mator users 256K Nov 12 19:25 half_sparse
kernel logs:
Nov 12 19:28:11 chubaka kernel: ISO 9660 Extensions: RRIP_1991A
Nov 12 19:28:50 chubaka kernel: BUG: Unable to handle kernel data
access on read at 0xfff01417f3f98000
Nov 12 19:28:50 chubaka kernel: Faulting instruction address: 0xc0000000000ad4b0
Nov 12 19:28:50 chubaka kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Nov 12 19:28:50 chubaka kernel: BE PAGE_SIZE=64K MMU=Hash SMP
NR_CPUS=2048 NUMA pSeries
Nov 12 19:28:50 chubaka kernel: Modules linked in: isofs(E) loop(E)
sg(E) drm(E) drm_panel_orientation_quirks(E) ip_tables(E) x_tables(E)
autofs4(E) ext4(E) crc16(E) mb>
Nov 12 19:28:50 chubaka kernel: CPU: 0 PID: 12433 Comm: md5sum
Tainted: G E 5.9.0-1-powerpc64 #1 Debian 5.9.1-1
Nov 12 19:28:50 chubaka kernel: NIP: c0000000000ad4b0 LR:
c008000001086628 CTR: 0000000000000200
Nov 12 19:28:50 chubaka kernel: REGS: c0000003f40fb3c0 TRAP: 0380
Tainted: G E (5.9.0-1-powerpc64 Debian 5.9.1-1)
Nov 12 19:28:50 chubaka kernel: MSR: 800000000280b032
<SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 44842440 XER: 00000000
Nov 12 19:28:50 chubaka kernel: CFAR: c0000000000ad46c IRQMASK: 0
GPR00: 0000000000000200
c0000003f40fb650 c00000000179a000 fff01417f3f98000
GPR04: 0000000000000000
0000000000000000 fff01417f3f98000 0000000000008082
GPR08: c00000000186d120
c8ebfc0505fcfe60 ffffffffffffffff c008000001087308
GPR12: c0000000000ad448
c0000000019a0000 0000000000000018 0000000000008000
GPR16: 0000000000000000
ffffffffffffffff 00000000000007ff 0000000000000800
GPR20: 00000000000007ff
000000000000000b c000000005fceb08 0000000000004ba3
GPR24: 0000000000000002
c0000003cddab8b0 0000000000004ba3 c0000003ad000a90
GPR28: 0000000000000004
0000000000000000 c000000005fceb00 0000000000000000
Nov 12 19:28:50 chubaka kernel: NIP [c0000000000ad4b0] .memset+0x68/0x104
Nov 12 19:28:50 chubaka kernel: LR [c008000001086628]
.zisofs_readpage+0xbd8/0xd90 [isofs]
Nov 12 19:28:50 chubaka kernel: Call Trace:
Nov 12 19:28:50 chubaka kernel: [c0000003f40fb650] [c008000001085ec0]
.zisofs_readpage+0x470/0xd90 [isofs] (unreliable)
Nov 12 19:28:50 chubaka kernel: [c0000003f40fb830] [c0000000003a4d08]
.read_pages+0x2f8/0x390
Nov 12 19:28:50 chubaka kernel: [c0000003f40fb900] [c0000000003a53b4]
.page_cache_readahead_unbounded+0x224/0x2f0
Nov 12 19:28:50 chubaka kernel: [c0000003f40fba20] [c0000000003960c4]
.generic_file_buffered_read+0x704/0xcf0
Nov 12 19:28:50 chubaka kernel: [c0000003f40fbb30] [c0000000004a132c]
.new_sync_read+0x13c/0x1e0
Nov 12 19:28:50 chubaka kernel: [c0000003f40fbc30] [c0000000004a5d50]
.vfs_read+0x1a0/0x210
Nov 12 19:28:50 chubaka kernel: [c0000003f40fbcd0] [c0000000004a6324]
.ksys_read+0x84/0x140
Nov 12 19:28:50 chubaka kernel: [c0000003f40fbd70] [c00000000002fd40]
.system_call_exception+0x140/0x260
Nov 12 19:28:50 chubaka kernel: [c0000003f40fbe20] [c00000000000e0a8]
system_call_common+0xe8/0x218
Nov 12 19:28:50 chubaka kernel: Instruction dump:
Nov 12 19:28:50 chubaka kernel: 409e000c b0860000 38c60002 409d000c
90860000 38c60004 78a0d183 78a506a0
Nov 12 19:28:50 chubaka kernel: 7c0903a6 41820034 60000000 60000000
<f8860000> f8860008 f8860010 f8860018
Nov 12 19:28:50 chubaka kernel: ---[ end trace 397c22c64113204a ]---
Nov 12 19:28:50 chubaka kernel:
Reply to: