Latest working kernel version: Earliest failing kernel version: Distribution: Debian sid (unstable) Hardware Environment: qemu x86 Software Environment: Minimal Debian sid Problem Description: The attached files, which are actually (intentionally) corrupted iso9660 filesystems, are recognized as V7 FS, whatever that is. Attempts to use the filesystem then results in an oops, which probably doesn't speak highly of that filesystem's robustness against corrupted filesystems. Steps to reproduce: For hdb.10007430.gz: 1. gunzip the image 2. mount the image with mount hdb.10007430 /mnt -o loop (it should be recognized as V7 FS) 3. umount /mnt - oops For hdb.20005046.gz: 1. gunzip the image 2. mount the image with mount hdb.20005046 /mnt -o loop (it should be recognized as V7 FS) 3. cd /mnt 4. cat a/b - oops
Created attachment 16425 [details] Test case 1, hdb.10007430, gzipped Here's the backtrace: fstest:~# mount /dev/hdb /mnt FAT: bogus number of reserved sectors VFS: Can't find a valid FAT filesystem on dev hdb. VFS: Found a V7 FS (block size = 512) on device hdb fstest:~# umount /mnt sysv_free_block: trying to free block not in datazone sysv_free_inode: inode 0,1,2 or nonexistent inode ------------[ cut here ]------------ kernel BUG at fs/inode.c:1068! invalid opcode: 0000 [#1] Pid: 638, comm: umount Not tainted (2.6.25.4 #3) EIP: 0060:[<c0270347>] EFLAGS: 00000287 CPU: 0 EIP is at generic_delete_inode+0xd1/0xd5 EAX: c1101218 EBX: c034ea32 ECX: 00000007 EDX: c747b244 ESI: c747b038 EDI: 00000000 EBP: c7acbe70 ESP: c7acbe68 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process umount (pid: 638, ti=c7aca000 task=c7aa8ea0 task.ti=c7aca000) Stack: c747b038 c74792f8 c7acbe80 c0270486 c747b038 c74792f8 c7acbe8c c026f4ae c747b038 c7acbec4 c026ded2 c7a76880 c7acbea8 00000002 c7acbebc c7acbf34 00000000 c026420e c7811050 00000001 c7937000 c055a800 c78d5100 c7acbed0 Call Trace: [<c0270486>] ? generic_drop_inode+0x13b/0x157 [<c026f4ae>] ? iput+0x64/0x6b [<c026ded2>] ? shrink_dcache_for_umount_subtree+0x18c/0x216 [<c026420e>] ? path_put+0x20/0x23 [<c026df83>] ? shrink_dcache_for_umount+0x27/0x46 [<c025f6d0>] ? generic_shutdown_super+0x1b/0xeb [<c025f7af>] ? kill_block_super+0xf/0x20 [<c025f850>] ? deactivate_super+0x3f/0x51 [<c027280b>] ? mntput_no_expire+0x44/0x67 [<c0272bfb>] ? sys_umount+0x41/0x2c1 [<c024e3ce>] ? unmap_region+0xb1/0xe9 [<c0260899>] ? vfs_stat+0x11/0x13 [<c02608af>] ? sys_stat64+0x14/0x28 [<c024f289>] ? do_munmap+0x1d0/0x224 [<c0272e94>] ? sys_oldumount+0x19/0x1b [<c0202cd2>] ? syscall_call+0x7/0xb ======================= Code: be 0c 02 00 00 40 75 23 89 f0 e8 ef f4 ff ff 5b 5e 5d c3 8d 86 10 01 00 00 31 d2 31 c9 e8 c8 6d fd ff 89 f0 e8 63 fa ff ff eb 91 <0f> 0b eb fe 55 89 e5 56 53 89 c3 8b 40 28 85 c0 0f 84 22 01 00 EIP: [<c0270347>] generic_delete_inode+0xd1/0xd5 SS:ESP 0068:c7acbe68 ---[ end trace bfa63688ca918885 ]---
Created attachment 16426 [details] Test case 2, hdb.20005046, gzipped And the backtrace for this bug, actually different from that in test case 1: fstest:~# mount /dev/hdb /mnt FAT: bogus number of reserved sectors VFS: Can't find a valid FAT filesystem on dev hdb. VFS: Found a V7 FS (block size = 512) on device hdb fstest:~# cd /mnt fstest:/mnt# cat a/b attempt to access beyond end of device hdb: rw=0, want=4097, limit=3928 Buffer I/O error on device hdb, logical block 4096 attempt to access beyond end of device hdb: rw=0, want=4097, limit=3928 Buffer I/O error on device hdb, logical block 4096 BUG: unable to handle kernel paging request at fffffffe IP: [<c020ea51>] kunmap+0x19/0x63 *pde = 00001067 *pte = 00000000 Oops: 0000 [#1] Pid: 638, comm: cat Not tainted (2.6.25.4 #3) EIP: 0060:[<c020ea51>] EFLAGS: 00000246 CPU: 0 EIP is at kunmap+0x19/0x63 EAX: c7ac2000 EBX: c7479558 ECX: fffffffb EDX: 00000000 ESI: c747b000 EDI: c7ac3f14 EBP: c7ac3d30 ESP: c7ac3d30 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process cat (pid: 638, ti=c7ac2000 task=c79e0ea0 task.ti=c7ac2000) Stack: c7ac3d7c c0350a5a 00000001 c026e2b3 00000002 00000001 c026e1fc 00000000 c7ac3d84 c74795cc c747b038 00000000 00000000 00000100 fffffffb c747b000 c7479558 c747b038 c7ac3f14 c7ac3d90 c0350a9e 00000000 c7479558 c747b038 Call Trace: [<c0350a5a>] ? sysv_find_entry+0xf1/0x123 [<c026e2b3>] ? __d_lookup+0x101/0x174 [<c026e1fc>] ? __d_lookup+0x4a/0x174 [<c0350a9e>] ? sysv_inode_by_name+0x12/0x4c [<c03510f0>] ? sysv_lookup+0x2e/0x6e [<c0264555>] ? do_lookup+0x15c/0x188 [<c02656c4>] ? __link_path_walk+0x116/0xd88 [<c0266380>] ? path_walk+0x4a/0x99 [<c02665a5>] ? do_path_lookup+0x82/0x1c6 [<c020d2e2>] ? do_page_fault+0x301/0x79f [<c0266976>] ? __path_lookup_intent_open+0x44/0x86 [<c02669d9>] ? path_lookup_open+0x21/0x27 [<c02673a9>] ? open_namei+0x5c/0x6a3 [<c0455649>] ? copy_to_user+0x3a/0x121 [<c02604f3>] ? cp_new_stat64+0xe4/0xf6 [<c025c1df>] ? do_filp_open+0x26/0x43 [<c053cfe1>] ? _spin_unlock+0x1d/0x20 [<c025bf31>] ? get_unused_fd_flags+0xa6/0xe0 [<c0455838>] ? strncpy_from_user+0x36/0x50 [<c025c245>] ? do_sys_open+0x49/0xd2 [<c025c31a>] ? sys_open+0x23/0x2b [<c0202cd2>] ? syscall_call+0x7/0xb ======================= Code: eb fe 55 89 e5 8b 0d 70 9b 66 c0 e8 34 ff ff ff 5d c3 55 89 e5 89 c1 89 e0 25 00 e0 ff ff f7 40 14 00 ff ff 0f 74 04 0f 0b eb fe <0f> b6 51 03 83 e2 03 8d 04 12 01 d0 01 c0 01 c0 29 d0 8d 04 c2 EIP: [<c020ea51>] kunmap+0x19/0x63 SS:ESP 0068:c7ac3d30 ---[ end trace f1d751c5df21d565 ]---
Seems to be fixed as of 2.6.27-rc