* Kernel 3.1.0-rc4 oops when connecting iPod
@ 2011-09-03 3:08 Pavel Ivanov
2011-09-03 3:59 ` Hin-Tak Leung
0 siblings, 1 reply; 45+ messages in thread
From: Pavel Ivanov @ 2011-09-03 3:08 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-kernel
Hi,
With kernel 3.1.0-rc4 any attempt to connect iPod to USB leads to
kernel oops. I'd say that stacktrace of the oops is pretty much random
and not related to HFS. But I was able to get useful info from it when
I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this case I don't get
oops but the following instead:
[ 81.508807] hfs: filesystem size too large.
[ 81.559295] =============================================================================
[ 81.656965] BUG kmalloc-4096: Invalid object pointer 0xffff880136160400
[ 81.735947] -----------------------------------------------------------------------------
[ 81.735948]
[ 81.851359] INFO: Slab 0xffffea0004d85800 objects=7 used=7 fp=0x
(null) flags=0x2000000000004081
[ 81.965628] Pid: 2086, comm: ipod-set-info Not tainted 3.1.0-rc4+ #2
[ 81.965629] Call Trace:
[ 81.965636] [<ffffffff8119359f>] slab_err+0xaf/0xd0
[ 81.965640] [<ffffffff8119381f>] ? slab_pad_check+0xaf/0x1a0
[ 81.965644] [<ffffffff8119719f>] free_debug_processing+0x1ef/0x310
[ 81.965647] [<ffffffff811974ba>] __slab_free+0x1fa/0x490
[ 81.965653] [<ffffffffa0516c4d>] ? hfsplus_fill_super+0x2ed/0x610 [hfsplus]
[ 81.965656] [<ffffffff81197a3c>] kfree+0x12c/0x150
[ 81.965660] [<ffffffffa0516c4d>] hfsplus_fill_super+0x2ed/0x610 [hfsplus]
[ 81.965665] [<ffffffff81438771>] ? ioctl_internal_command.clone.4+0x61/0x1b0
[ 81.965671] [<ffffffff8161fe9e>] ? _raw_spin_unlock+0xe/0x40
[ 81.965675] [<ffffffff81195eb8>] ? deactivate_slab+0x578/0x750
[ 81.965679] [<ffffffff811af3cb>] ? sget+0xab/0x480
[ 81.965683] [<ffffffff8133f0c9>] ? put_dec+0x59/0x60
[ 81.965685] [<ffffffff813407d1>] ? number.clone.2+0x311/0x350
[ 81.965690] [<ffffffff8116bd7b>] ? pcpu_alloc_area+0x10b/0x2c0
[ 81.965693] [<ffffffff81341b81>] ? vsnprintf+0x471/0x610
[ 81.965696] [<ffffffff8116c639>] ? pcpu_alloc+0x399/0x9e0
[ 81.965699] [<ffffffff81341dc4>] ? snprintf+0x34/0x40
[ 81.965702] [<ffffffff8133ebc6>] ? strlcpy+0x46/0x60
[ 81.965707] [<ffffffff8115bfb2>] ? register_shrinker+0x52/0x60
[ 81.965710] [<ffffffff811afa26>] mount_bdev+0x1c6/0x210
[ 81.965714] [<ffffffffa0516960>] ? hfsplus_iget+0x240/0x240 [hfsplus]
[ 81.965718] [<ffffffffa05160a5>] hfsplus_mount+0x15/0x20 [hfsplus]
[ 81.965720] [<ffffffff811b0547>] mount_fs+0x47/0x1c0
[ 81.965723] [<ffffffff8116cc90>] ? __alloc_percpu+0x10/0x20
[ 81.965727] [<ffffffff811ca383>] vfs_kern_mount+0x63/0xd0
[ 81.965731] [<ffffffff811cb4d4>] do_kern_mount+0x54/0x110
[ 81.965734] [<ffffffff811cd022>] do_mount+0x502/0x7e0
[ 81.965736] [<ffffffff8116738b>] ? strndup_user+0x5b/0x80
[ 81.965739] [<ffffffff811cd710>] sys_mount+0x90/0xe0
[ 81.965744] [<ffffffff81627402>] system_call_fastpath+0x16/0x1b
[ 81.965746] FIX kmalloc-4096: Object at 0xffff880136160400 not freed
Following by 2 other bugs with the same stack trace.
(BTW, before oops first message "hfs: filesystem size too large"
always appears twice.)
Another question: is hfsplus supposed to work at all? I see it's
marked as "Orphaned" in MAINTAINERS and on attempt to connect iPod
with kernel 2.6.38.11 (standard kernel in Ubuntu 11.04) I still don't
get it working. Although without oops I get the following messages:
[ 65.479360] usb 2-3: new high speed USB device using ehci_hcd and address 4
[ 65.686470] usbcore: registered new interface driver uas
[ 65.706455] Initializing USB Mass Storage driver...
[ 65.706901] scsi4 : usb-storage 2-3:1.0
[ 65.707251] usbcore: registered new interface driver usb-storage
[ 65.707254] USB Mass Storage support registered.
[ 66.702320] scsi 4:0:0:0: Direct-Access Apple iPod
1.62 PQ: 0 ANSI: 0
[ 66.704537] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 66.809047] sd 4:0:0:0: [sdb] 1946049 4096-byte logical blocks:
(7.97 GB/7.42 GiB)
[ 66.809930] sd 4:0:0:0: [sdb] Write Protect is off
[ 66.809935] sd 4:0:0:0: [sdb] Mode Sense: 68 00 00 08
[ 66.809938] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 66.885037] sd 4:0:0:0: [sdb] 1946049 4096-byte logical blocks:
(7.97 GB/7.42 GiB)
[ 66.885933] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 66.979400] sdb: [mac] sdb1 sdb2
[ 66.981940] sd 4:0:0:0: [sdb] 1946049 4096-byte logical blocks:
(7.97 GB/7.42 GiB)
[ 66.982834] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 67.055808] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[ 67.299357] sd 4:0:0:0: [sdb] Bad block number requested
[ 67.362982] hfs: unable to find HFS+ superblock
[ 67.499457] sd 4:0:0:0: [sdb] Bad block number requested
[ 67.563085] hfs: unable to find HFS+ superblock
Thank you,
Pavel
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 3:08 Kernel 3.1.0-rc4 oops when connecting iPod Pavel Ivanov @ 2011-09-03 3:59 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-03 3:59 UTC (permalink / raw) To: linux-fsdevel, Pavel Ivanov; +Cc: linux-kernel --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > Hi, > > With kernel 3.1.0-rc4 any attempt to connect iPod to USB > leads to > kernel oops. I'd say that stacktrace of the oops is pretty > much random > and not related to HFS. But I was able to get useful info > from it when > I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this case I > don't get > oops but the following instead: There are a few hfsplus related changes to do protection against invalid data like this, but may be there are more. It would be useful to have the output from your objdump -l -d hfsplus.ko | grep -A 1000 '<hfsplus_fill_super>' (the -l gives line numbers against the kernel tree, so would be useful if you run this against the ko there...) > > [ 81.508807] hfs: filesystem size too > large. > [ 81.559295] > ============================================================================= > [ 81.656965] BUG kmalloc-4096: Invalid > object pointer 0xffff880136160400 > [ 81.735947] > ----------------------------------------------------------------------------- > [ 81.735948] > [ 81.851359] INFO: Slab 0xffffea0004d85800 > objects=7 used=7 fp=0x > (null) flags=0x2000000000004081 > [ 81.965628] Pid: 2086, comm: > ipod-set-info Not tainted 3.1.0-rc4+ #2 > [ 81.965629] Call Trace: > [ 81.965636] > [<ffffffff8119359f>] slab_err+0xaf/0xd0 > [ 81.965640] > [<ffffffff8119381f>] ? slab_pad_check+0xaf/0x1a0 > [ 81.965644] > [<ffffffff8119719f>] > free_debug_processing+0x1ef/0x310 > [ 81.965647] > [<ffffffff811974ba>] __slab_free+0x1fa/0x490 > [ 81.965653] > [<ffffffffa0516c4d>] ? hfsplus_fill_super+0x2ed/0x610 > [hfsplus] > [ 81.965656] > [<ffffffff81197a3c>] kfree+0x12c/0x150 > [ 81.965660] > [<ffffffffa0516c4d>] hfsplus_fill_super+0x2ed/0x610 > [hfsplus] > [ 81.965665] > [<ffffffff81438771>] ? > ioctl_internal_command.clone.4+0x61/0x1b0 > [ 81.965671] > [<ffffffff8161fe9e>] ? _raw_spin_unlock+0xe/0x40 > [ 81.965675] > [<ffffffff81195eb8>] ? deactivate_slab+0x578/0x750 > [ 81.965679] > [<ffffffff811af3cb>] ? sget+0xab/0x480 > [ 81.965683] > [<ffffffff8133f0c9>] ? put_dec+0x59/0x60 > [ 81.965685] > [<ffffffff813407d1>] ? number.clone.2+0x311/0x350 > [ 81.965690] > [<ffffffff8116bd7b>] ? pcpu_alloc_area+0x10b/0x2c0 > [ 81.965693] > [<ffffffff81341b81>] ? vsnprintf+0x471/0x610 > [ 81.965696] > [<ffffffff8116c639>] ? pcpu_alloc+0x399/0x9e0 > [ 81.965699] > [<ffffffff81341dc4>] ? snprintf+0x34/0x40 > [ 81.965702] > [<ffffffff8133ebc6>] ? strlcpy+0x46/0x60 > [ 81.965707] > [<ffffffff8115bfb2>] ? register_shrinker+0x52/0x60 > [ 81.965710] > [<ffffffff811afa26>] mount_bdev+0x1c6/0x210 > [ 81.965714] > [<ffffffffa0516960>] ? hfsplus_iget+0x240/0x240 > [hfsplus] > [ 81.965718] > [<ffffffffa05160a5>] hfsplus_mount+0x15/0x20 > [hfsplus] > [ 81.965720] > [<ffffffff811b0547>] mount_fs+0x47/0x1c0 > [ 81.965723] > [<ffffffff8116cc90>] ? __alloc_percpu+0x10/0x20 > [ 81.965727] > [<ffffffff811ca383>] vfs_kern_mount+0x63/0xd0 > [ 81.965731] > [<ffffffff811cb4d4>] do_kern_mount+0x54/0x110 > [ 81.965734] > [<ffffffff811cd022>] do_mount+0x502/0x7e0 > [ 81.965736] > [<ffffffff8116738b>] ? strndup_user+0x5b/0x80 > [ 81.965739] > [<ffffffff811cd710>] sys_mount+0x90/0xe0 > [ 81.965744] > [<ffffffff81627402>] system_call_fastpath+0x16/0x1b > [ 81.965746] FIX kmalloc-4096: Object at > 0xffff880136160400 not freed > > Following by 2 other bugs with the same stack trace. > > (BTW, before oops first message "hfs: filesystem size too > large" > always appears twice.) > > > Another question: is hfsplus supposed to work at all? I see > it's > marked as "Orphaned" in MAINTAINERS and on attempt to > connect iPod > with kernel 2.6.38.11 (standard kernel in Ubuntu 11.04) I > still don't > get it working. Although without oops I get the following > messages: > > [ 65.479360] usb 2-3: new high speed USB > device using ehci_hcd and address 4 > [ 65.686470] usbcore: registered new > interface driver uas > [ 65.706455] Initializing USB Mass Storage > driver... > [ 65.706901] scsi4 : usb-storage 2-3:1.0 > [ 65.707251] usbcore: registered new > interface driver usb-storage > [ 65.707254] USB Mass Storage support > registered. > [ 66.702320] scsi 4:0:0:0: > Direct-Access Apple > iPod > 1.62 PQ: 0 ANSI: 0 > [ 66.704537] sd 4:0:0:0: Attached scsi > generic sg2 type 0 > [ 66.809047] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.809930] sd 4:0:0:0: [sdb] Write > Protect is off > [ 66.809935] sd 4:0:0:0: [sdb] Mode Sense: > 68 00 00 08 > [ 66.809938] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 66.885037] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.885933] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 66.979400] sdb: [mac] sdb1 sdb2 > [ 66.981940] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.982834] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 67.055808] sd 4:0:0:0: [sdb] Attached > SCSI removable disk > [ 67.299357] sd 4:0:0:0: [sdb] Bad block > number requested > [ 67.362982] hfs: unable to find HFS+ > superblock > [ 67.499457] sd 4:0:0:0: [sdb] Bad block > number requested > [ 67.563085] hfs: unable to find HFS+ > superblock > > > Thank you, > Pavel > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-03 3:59 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-03 3:59 UTC (permalink / raw) To: linux-fsdevel, Pavel Ivanov; +Cc: linux-kernel --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > Hi, > > With kernel 3.1.0-rc4 any attempt to connect iPod to USB > leads to > kernel oops. I'd say that stacktrace of the oops is pretty > much random > and not related to HFS. But I was able to get useful info > from it when > I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this case I > don't get > oops but the following instead: There are a few hfsplus related changes to do protection against invalid data like this, but may be there are more. It would be useful to have the output from your objdump -l -d hfsplus.ko | grep -A 1000 '<hfsplus_fill_super>' (the -l gives line numbers against the kernel tree, so would be useful if you run this against the ko there...) > > [ 81.508807] hfs: filesystem size too > large. > [ 81.559295] > ============================================================================= > [ 81.656965] BUG kmalloc-4096: Invalid > object pointer 0xffff880136160400 > [ 81.735947] > ----------------------------------------------------------------------------- > [ 81.735948] > [ 81.851359] INFO: Slab 0xffffea0004d85800 > objects=7 used=7 fp=0x > (null) flags=0x2000000000004081 > [ 81.965628] Pid: 2086, comm: > ipod-set-info Not tainted 3.1.0-rc4+ #2 > [ 81.965629] Call Trace: > [ 81.965636] > [<ffffffff8119359f>] slab_err+0xaf/0xd0 > [ 81.965640] > [<ffffffff8119381f>] ? slab_pad_check+0xaf/0x1a0 > [ 81.965644] > [<ffffffff8119719f>] > free_debug_processing+0x1ef/0x310 > [ 81.965647] > [<ffffffff811974ba>] __slab_free+0x1fa/0x490 > [ 81.965653] > [<ffffffffa0516c4d>] ? hfsplus_fill_super+0x2ed/0x610 > [hfsplus] > [ 81.965656] > [<ffffffff81197a3c>] kfree+0x12c/0x150 > [ 81.965660] > [<ffffffffa0516c4d>] hfsplus_fill_super+0x2ed/0x610 > [hfsplus] > [ 81.965665] > [<ffffffff81438771>] ? > ioctl_internal_command.clone.4+0x61/0x1b0 > [ 81.965671] > [<ffffffff8161fe9e>] ? _raw_spin_unlock+0xe/0x40 > [ 81.965675] > [<ffffffff81195eb8>] ? deactivate_slab+0x578/0x750 > [ 81.965679] > [<ffffffff811af3cb>] ? sget+0xab/0x480 > [ 81.965683] > [<ffffffff8133f0c9>] ? put_dec+0x59/0x60 > [ 81.965685] > [<ffffffff813407d1>] ? number.clone.2+0x311/0x350 > [ 81.965690] > [<ffffffff8116bd7b>] ? pcpu_alloc_area+0x10b/0x2c0 > [ 81.965693] > [<ffffffff81341b81>] ? vsnprintf+0x471/0x610 > [ 81.965696] > [<ffffffff8116c639>] ? pcpu_alloc+0x399/0x9e0 > [ 81.965699] > [<ffffffff81341dc4>] ? snprintf+0x34/0x40 > [ 81.965702] > [<ffffffff8133ebc6>] ? strlcpy+0x46/0x60 > [ 81.965707] > [<ffffffff8115bfb2>] ? register_shrinker+0x52/0x60 > [ 81.965710] > [<ffffffff811afa26>] mount_bdev+0x1c6/0x210 > [ 81.965714] > [<ffffffffa0516960>] ? hfsplus_iget+0x240/0x240 > [hfsplus] > [ 81.965718] > [<ffffffffa05160a5>] hfsplus_mount+0x15/0x20 > [hfsplus] > [ 81.965720] > [<ffffffff811b0547>] mount_fs+0x47/0x1c0 > [ 81.965723] > [<ffffffff8116cc90>] ? __alloc_percpu+0x10/0x20 > [ 81.965727] > [<ffffffff811ca383>] vfs_kern_mount+0x63/0xd0 > [ 81.965731] > [<ffffffff811cb4d4>] do_kern_mount+0x54/0x110 > [ 81.965734] > [<ffffffff811cd022>] do_mount+0x502/0x7e0 > [ 81.965736] > [<ffffffff8116738b>] ? strndup_user+0x5b/0x80 > [ 81.965739] > [<ffffffff811cd710>] sys_mount+0x90/0xe0 > [ 81.965744] > [<ffffffff81627402>] system_call_fastpath+0x16/0x1b > [ 81.965746] FIX kmalloc-4096: Object at > 0xffff880136160400 not freed > > Following by 2 other bugs with the same stack trace. > > (BTW, before oops first message "hfs: filesystem size too > large" > always appears twice.) > > > Another question: is hfsplus supposed to work at all? I see > it's > marked as "Orphaned" in MAINTAINERS and on attempt to > connect iPod > with kernel 2.6.38.11 (standard kernel in Ubuntu 11.04) I > still don't > get it working. Although without oops I get the following > messages: > > [ 65.479360] usb 2-3: new high speed USB > device using ehci_hcd and address 4 > [ 65.686470] usbcore: registered new > interface driver uas > [ 65.706455] Initializing USB Mass Storage > driver... > [ 65.706901] scsi4 : usb-storage 2-3:1.0 > [ 65.707251] usbcore: registered new > interface driver usb-storage > [ 65.707254] USB Mass Storage support > registered. > [ 66.702320] scsi 4:0:0:0: > Direct-Access Apple > iPod > 1.62 PQ: 0 ANSI: 0 > [ 66.704537] sd 4:0:0:0: Attached scsi > generic sg2 type 0 > [ 66.809047] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.809930] sd 4:0:0:0: [sdb] Write > Protect is off > [ 66.809935] sd 4:0:0:0: [sdb] Mode Sense: > 68 00 00 08 > [ 66.809938] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 66.885037] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.885933] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 66.979400] sdb: [mac] sdb1 sdb2 > [ 66.981940] sd 4:0:0:0: [sdb] 1946049 > 4096-byte logical blocks: > (7.97 GB/7.42 GiB) > [ 66.982834] sd 4:0:0:0: [sdb] Assuming > drive cache: write through > [ 67.055808] sd 4:0:0:0: [sdb] Attached > SCSI removable disk > [ 67.299357] sd 4:0:0:0: [sdb] Bad block > number requested > [ 67.362982] hfs: unable to find HFS+ > superblock > [ 67.499457] sd 4:0:0:0: [sdb] Bad block > number requested > [ 67.563085] hfs: unable to find HFS+ > superblock > > > Thank you, > Pavel > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 3:59 ` Hin-Tak Leung (?) @ 2011-09-03 4:37 ` Pavel Ivanov 2011-09-03 6:57 ` Hin-Tak Leung -1 siblings, 1 reply; 45+ messages in thread From: Pavel Ivanov @ 2011-09-03 4:37 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 832 bytes --] On Fri, Sep 2, 2011 at 11:59 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> With kernel 3.1.0-rc4 any attempt to connect iPod to USB >> leads to >> kernel oops. I'd say that stacktrace of the oops is pretty >> much random >> and not related to HFS. But I was able to get useful info >> from it when >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this case I >> don't get >> oops but the following instead: > > There are a few hfsplus related changes to do protection against invalid data like this, but may be there are more. It would be useful to have the output from your > objdump -l -d hfsplus.ko | grep -A 1000 '<hfsplus_fill_super>' > (the -l gives line numbers against the kernel tree, so would be useful if you run this against the ko there...) Output of this command is in attachment. Pavel [-- Attachment #2: hfsplus.dump --] [-- Type: application/octet-stream, Size: 53483 bytes --] 0000000000000960 <hfsplus_fill_super>: hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:339 960: 55 push %rbp 961: 48 89 e5 mov %rsp,%rbp 964: 41 57 push %r15 966: 41 56 push %r14 968: 41 55 push %r13 96a: 41 54 push %r12 96c: 53 push %rbx 96d: 48 81 ec 78 02 00 00 sub $0x278,%rsp 974: e8 00 00 00 00 callq 979 <hfsplus_fill_super+0x19> 979: 49 89 fc mov %rdi,%r12 97c: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax 983: 00 00 985: 48 89 45 c8 mov %rax,-0x38(%rbp) 989: 31 c0 xor %eax,%eax kmalloc_slab(): /home/pivanof/def_workspace/linux/include/linux/slub_def.h:210 98b: 48 8b 3d 00 00 00 00 mov 0x0(%rip),%rdi # 992 <hfsplus_fill_super+0x32> hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:339 992: 49 89 f7 mov %rsi,%r15 995: 41 89 d5 mov %edx,%r13d kmalloc(): /home/pivanof/def_workspace/linux/include/linux/slub_def.h:270 998: 48 85 ff test %rdi,%rdi 99b: 0f 84 bf 02 00 00 je c60 <hfsplus_fill_super+0x300> /home/pivanof/def_workspace/linux/include/linux/slub_def.h:273 9a1: ba 00 01 00 00 mov $0x100,%edx 9a6: be d0 80 00 00 mov $0x80d0,%esi hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:349 9ab: 41 be ea ff ff ff mov $0xffffffea,%r14d kmalloc(): /home/pivanof/def_workspace/linux/include/linux/slub_def.h:273 9b1: e8 00 00 00 00 callq 9b6 <hfsplus_fill_super+0x56> 9b6: 48 89 c3 mov %rax,%rbx hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:351 9b9: 48 85 c0 test %rax,%rax 9bc: 0f 84 b6 00 00 00 je a78 <hfsplus_fill_super+0x118> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:355 9c2: 48 8d bb 88 00 00 00 lea 0x88(%rbx),%rdi 9c9: 48 c7 c2 00 00 00 00 mov $0x0,%rdx 9d0: 48 c7 c6 00 00 00 00 mov $0x0,%rsi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:354 9d7: 49 89 9c 24 b0 02 00 mov %rbx,0x2b0(%r12) 9de: 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:355 9df: e8 00 00 00 00 callq 9e4 <hfsplus_fill_super+0x84> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:356 9e4: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 9eb: 48 8d 93 b8 00 00 00 lea 0xb8(%rbx),%rdx 9f2: 48 89 95 68 fd ff ff mov %rdx,-0x298(%rbp) 9f9: 48 c7 c2 00 00 00 00 mov $0x0,%rdx a00: 48 8b bd 68 fd ff ff mov -0x298(%rbp),%rdi a07: e8 00 00 00 00 callq a0c <hfsplus_fill_super+0xac> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:357 a0c: 48 89 df mov %rbx,%rdi a0f: e8 00 00 00 00 callq a14 <hfsplus_fill_super+0xb4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:360 a14: 48 89 de mov %rbx,%rsi a17: 4c 89 ff mov %r15,%rdi a1a: e8 00 00 00 00 callq a1f <hfsplus_fill_super+0xbf> a1f: 85 c0 test %eax,%eax a21: 0f 84 52 04 00 00 je e79 <hfsplus_fill_super+0x519> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:366 a27: 4c 8b 7b 48 mov 0x48(%rbx),%r15 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:367 a2b: 48 c7 c7 00 00 00 00 mov $0x0,%rdi a32: e8 00 00 00 00 callq a37 <hfsplus_fill_super+0xd7> a37: 48 89 43 48 mov %rax,0x48(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:368 a3b: 48 85 c0 test %rax,%rax a3e: 0f 84 4f 04 00 00 je e93 <hfsplus_fill_super+0x533> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:374 a44: 4c 89 e7 mov %r12,%rdi a47: e8 00 00 00 00 callq a4c <hfsplus_fill_super+0xec> a4c: 85 c0 test %eax,%eax a4e: 74 50 je aa0 <hfsplus_fill_super+0x140> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:375 a50: 45 85 ed test %r13d,%r13d a53: 0f 84 ae 04 00 00 je f07 <hfsplus_fill_super+0x5a7> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:359 a59: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:531 a5f: 48 8b 7b 48 mov 0x48(%rbx),%rdi a63: e8 00 00 00 00 callq a68 <hfsplus_fill_super+0x108> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:532 a68: 4c 89 ff mov %r15,%rdi a6b: e8 00 00 00 00 callq a70 <hfsplus_fill_super+0x110> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:533 a70: 48 89 df mov %rbx,%rdi a73: e8 00 00 00 00 callq a78 <hfsplus_fill_super+0x118> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:536 a78: 44 89 f0 mov %r14d,%eax a7b: 48 8b 55 c8 mov -0x38(%rbp),%rdx a7f: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx a86: 00 00 a88: 0f 85 e6 03 00 00 jne e74 <hfsplus_fill_super+0x514> a8e: 48 81 c4 78 02 00 00 add $0x278,%rsp a95: 5b pop %rbx a96: 41 5c pop %r12 a98: 41 5d pop %r13 a9a: 41 5e pop %r14 a9c: 41 5f pop %r15 a9e: c9 leaveq a9f: c3 retq /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:379 aa0: 4c 8b 6b 08 mov 0x8(%rbx),%r13 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:382 aa4: 49 c7 44 24 58 2b 48 movq $0x482b,0x58(%r12) aab: 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:383 aad: 41 0f b7 45 02 movzwl 0x2(%r13),%eax __fswab16(): /home/pivanof/def_workspace/linux/include/linux/swab.h:51 ab2: 66 c1 c0 08 rol $0x8,%ax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:383 ab6: 0f b7 c0 movzwl %ax,%eax ab9: 83 f8 03 cmp $0x3,%eax abc: 0f 8e ca 02 00 00 jle d8c <hfsplus_fill_super+0x42c> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:384 ac2: 83 f8 05 cmp $0x5,%eax ac5: 0f 8f c1 02 00 00 jg d8c <hfsplus_fill_super+0x42c> __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 acb: 41 8b 75 2c mov 0x2c(%r13),%esi hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:394 acf: 8b 4b 70 mov 0x70(%rbx),%ecx __fswab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 ad2: 0f ce bswap %esi hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:388 ad4: 89 73 74 mov %esi,0x74(%rbx) __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 ad7: 41 8b 45 30 mov 0x30(%r13),%eax adb: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:389 add: 89 83 80 00 00 00 mov %eax,0x80(%rbx) __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 ae3: 41 8b 45 40 mov 0x40(%r13),%eax ae7: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:390 ae9: 89 83 a8 00 00 00 mov %eax,0xa8(%rbx) __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 aef: 41 8b 45 20 mov 0x20(%r13),%eax af3: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:391 af5: 89 83 ac 00 00 00 mov %eax,0xac(%rbx) __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 afb: 41 8b 45 24 mov 0x24(%r13),%eax aff: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:392 b01: 89 83 b0 00 00 00 mov %eax,0xb0(%rbx) __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 b07: 41 8b 45 3c mov 0x3c(%r13),%eax b0b: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:394 b0d: d3 e8 shr %cl,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:393 b0f: 89 43 78 mov %eax,0x78(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:395 b12: 85 c0 test %eax,%eax b14: 0f 84 56 01 00 00 je c70 <hfsplus_fill_super+0x310> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:398 b1a: 41 8b 45 38 mov 0x38(%r13),%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:400 b1e: ba 01 00 00 00 mov $0x1,%edx /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:402 b23: 89 f6 mov %esi,%esi b25: 89 cf mov %ecx,%edi __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 b27: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:398 b29: d3 e8 shr %cl,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:400 b2b: 85 c0 test %eax,%eax b2d: 0f 45 d0 cmovne %eax,%edx b30: 89 53 7c mov %edx,0x7c(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:402 b33: e8 00 00 00 00 callq b38 <hfsplus_fill_super+0x1d8> b38: 41 89 c6 mov %eax,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:404 b3b: 85 c0 test %eax,%eax b3d: 0f 85 0d 04 00 00 jne f50 <hfsplus_fill_super+0x5f0> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:410 b43: 49 c7 44 24 30 00 00 movq $0x0,0x30(%r12) b4a: 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:411 b4c: 49 b8 ff ff ff ff ff movabs $0x7fffffffffffffff,%r8 b53: ff ff 7f b56: 4d 89 44 24 20 mov %r8,0x20(%r12) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:413 b5b: 41 f6 45 06 01 testb $0x1,0x6(%r13) b60: 0f 84 71 03 00 00 je ed7 <hfsplus_fill_super+0x577> test_and_clear_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:250 b66: f0 0f ba b3 f8 00 00 lock btrl $0x2,0xf8(%rbx) b6d: 00 02 b6f: 19 c0 sbb %eax,%eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:419 b71: 85 c0 test %eax,%eax b73: 0f 84 07 01 00 00 je c80 <hfsplus_fill_super+0x320> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:436 b79: be 03 00 00 00 mov $0x3,%esi b7e: 4c 89 e7 mov %r12,%rdi b81: e8 00 00 00 00 callq b86 <hfsplus_fill_super+0x226> b86: 48 89 43 20 mov %rax,0x20(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:437 b8a: 48 85 c0 test %rax,%rax b8d: 0f 84 5d 03 00 00 je ef0 <hfsplus_fill_super+0x590> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:441 b93: be 04 00 00 00 mov $0x4,%esi b98: 4c 89 e7 mov %r12,%rdi b9b: e8 00 00 00 00 callq ba0 <hfsplus_fill_super+0x240> ba0: 48 89 43 28 mov %rax,0x28(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:442 ba4: 48 85 c0 test %rax,%rax ba7: 0f 84 73 03 00 00 je f20 <hfsplus_fill_super+0x5c0> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:447 bad: be 06 00 00 00 mov $0x6,%esi bb2: 4c 89 e7 mov %r12,%rdi bb5: e8 00 00 00 00 callq bba <hfsplus_fill_super+0x25a> bba: 49 89 c6 mov %rax,%r14 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:448 bbd: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax bc3: 0f 87 e1 02 00 00 ja eaa <hfsplus_fill_super+0x54a> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:453 bc9: 48 89 43 38 mov %rax,0x38(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:456 bcd: be 02 00 00 00 mov $0x2,%esi bd2: 4c 89 e7 mov %r12,%rdi bd5: e8 00 00 00 00 callq bda <hfsplus_fill_super+0x27a> bda: 48 89 85 60 fd ff ff mov %rax,-0x2a0(%rbp) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:457 be1: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax be7: 0f 87 d0 02 00 00 ja ebd <hfsplus_fill_super+0x55d> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:463 bed: c7 85 b4 fd ff ff 1d movl $0x1d,-0x24c(%rbp) bf4: 00 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:464 bf7: 48 c7 85 b8 fd ff ff movq $0x0,-0x248(%rbp) bfe: 00 00 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:465 c02: 48 8b 7b 28 mov 0x28(%rbx),%rdi c06: 48 8d b5 70 fd ff ff lea -0x290(%rbp),%rsi c0d: e8 00 00 00 00 callq c12 <hfsplus_fill_super+0x2b2> c12: 41 89 c6 mov %eax,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:466 c15: 85 c0 test %eax,%eax c17: 0f 84 a3 00 00 00 je cc0 <hfsplus_fill_super+0x360> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:520 c1d: 48 8b bd 60 fd ff ff mov -0x2a0(%rbp),%rdi c24: e8 00 00 00 00 callq c29 <hfsplus_fill_super+0x2c9> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:522 c29: 48 8b 7b 38 mov 0x38(%rbx),%rdi c2d: e8 00 00 00 00 callq c32 <hfsplus_fill_super+0x2d2> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:524 c32: 48 8b 7b 28 mov 0x28(%rbx),%rdi c36: e8 00 00 00 00 callq c3b <hfsplus_fill_super+0x2db> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:526 c3b: 48 8b 7b 20 mov 0x20(%rbx),%rdi c3f: e8 00 00 00 00 callq c44 <hfsplus_fill_super+0x2e4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:528 c44: 48 8b 7b 08 mov 0x8(%rbx),%rdi c48: e8 00 00 00 00 callq c4d <hfsplus_fill_super+0x2ed> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:529 c4d: 48 8b 7b 18 mov 0x18(%rbx),%rdi c51: e8 00 00 00 00 callq c56 <hfsplus_fill_super+0x2f6> c56: e9 04 fe ff ff jmpq a5f <hfsplus_fill_super+0xff> c5b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) kmalloc(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:350 c60: bb 10 00 00 00 mov $0x10,%ebx c65: e9 58 fd ff ff jmpq 9c2 <hfsplus_fill_super+0x62> c6a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:396 c70: c7 43 78 01 00 00 00 movl $0x1,0x78(%rbx) c77: e9 9e fe ff ff jmpq b1a <hfsplus_fill_super+0x1ba> c7c: 0f 1f 40 00 nopl 0x0(%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:421 c80: 41 8b 45 04 mov 0x4(%r13),%eax c84: a9 00 00 80 00 test $0x800000,%eax c89: 0f 85 a8 02 00 00 jne f37 <hfsplus_fill_super+0x5d7> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:424 c8f: a9 00 00 20 00 test $0x200000,%eax c94: 0f 84 df fe ff ff je b79 <hfsplus_fill_super+0x219> c9a: 41 f6 44 24 50 01 testb $0x1,0x50(%r12) ca0: 0f 85 d3 fe ff ff jne b79 <hfsplus_fill_super+0x219> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:426 ca6: 48 c7 c7 00 00 00 00 mov $0x0,%rdi cad: 31 c0 xor %eax,%eax caf: e8 00 00 00 00 callq cb4 <hfsplus_fill_super+0x354> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:430 cb4: 49 83 4c 24 50 01 orq $0x1,0x50(%r12) cba: e9 ba fe ff ff jmpq b79 <hfsplus_fill_super+0x219> cbf: 90 nop /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:468 cc0: 48 8d 8d b0 fd ff ff lea -0x250(%rbp),%rcx cc7: ba 02 00 00 00 mov $0x2,%edx ccc: 48 8b b5 70 fd ff ff mov -0x290(%rbp),%rsi cd3: 4c 89 e7 mov %r12,%rdi cd6: e8 00 00 00 00 callq cdb <hfsplus_fill_super+0x37b> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:469 cdb: ba 08 02 00 00 mov $0x208,%edx ce0: 48 8d b5 c0 fd ff ff lea -0x240(%rbp),%rsi ce7: 48 8d bd 70 fd ff ff lea -0x290(%rbp),%rdi cee: e8 00 00 00 00 callq cf3 <hfsplus_fill_super+0x393> cf3: 85 c0 test %eax,%eax cf5: 75 49 jne d40 <hfsplus_fill_super+0x3e0> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:470 cf7: 48 8d bd 70 fd ff ff lea -0x290(%rbp),%rdi cfe: e8 00 00 00 00 callq d03 <hfsplus_fill_super+0x3a3> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:471 d03: 66 81 bd c0 fd ff ff cmpw $0x100,-0x240(%rbp) d0a: 00 01 d0c: 0f 85 0b ff ff ff jne c1d <hfsplus_fill_super+0x2bd> __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 d12: 8b 85 c8 fd ff ff mov -0x238(%rbp),%eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:473 d18: 4c 89 e7 mov %r12,%rdi __fswab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 d1b: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:473 d1d: 89 c6 mov %eax,%esi d1f: e8 00 00 00 00 callq d24 <hfsplus_fill_super+0x3c4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:474 d24: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax d2a: 0f 87 33 02 00 00 ja f63 <hfsplus_fill_super+0x603> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:478 d30: 48 89 43 40 mov %rax,0x40(%rbx) d34: eb 16 jmp d4c <hfsplus_fill_super+0x3ec> d36: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) d3d: 00 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:480 d40: 48 8d bd 70 fd ff ff lea -0x290(%rbp),%rdi d47: e8 00 00 00 00 callq d4c <hfsplus_fill_super+0x3ec> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:482 d4c: 41 f6 44 24 50 01 testb $0x1,0x50(%r12) d52: 74 54 je da8 <hfsplus_fill_super+0x448> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:506 d54: 49 c7 84 24 f0 02 00 movq $0x0,0x2f0(%r12) d5b: 00 00 00 00 00 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:507 d60: 48 8b bd 60 fd ff ff mov -0x2a0(%rbp),%rdi d67: e8 00 00 00 00 callq d6c <hfsplus_fill_super+0x40c> d6c: 49 89 44 24 60 mov %rax,0x60(%r12) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:508 d71: 48 85 c0 test %rax,%rax d74: 0f 84 e6 00 00 00 je e60 <hfsplus_fill_super+0x500> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:513 d7a: 48 8b 7b 48 mov 0x48(%rbx),%rdi d7e: e8 00 00 00 00 callq d83 <hfsplus_fill_super+0x423> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:514 d83: 4c 89 7b 48 mov %r15,0x48(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:515 d87: e9 ec fc ff ff jmpq a78 <hfsplus_fill_super+0x118> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:385 d8c: 48 c7 c7 00 00 00 00 mov $0x0,%rdi d93: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:359 d95: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:385 d9b: e8 00 00 00 00 callq da0 <hfsplus_fill_super+0x440> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:386 da0: e9 9f fe ff ff jmpq c44 <hfsplus_fill_super+0x2e4> da5: 0f 1f 00 nopl (%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:487 da8: 41 c7 45 08 48 2b 4c movl $0x784c2b48,0x8(%r13) daf: 78 /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:488 db0: e8 00 00 00 00 callq db5 <hfsplus_fill_super+0x455> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:492 db5: be 01 00 00 00 mov $0x1,%esi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:488 dba: 05 80 b0 25 7c add $0x7c25b080,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:492 dbf: 4c 89 e7 mov %r12,%rdi __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 dc2: 0f c8 bswap %eax hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:488 dc4: 41 89 45 14 mov %eax,0x14(%r13) be32_add_cpu(): /home/pivanof/def_workspace/linux/include/linux/byteorder/generic.h:165 dc8: 41 8b 45 44 mov 0x44(%r13),%eax __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 dcc: 0f c8 bswap %eax be32_add_cpu(): /home/pivanof/def_workspace/linux/include/linux/byteorder/generic.h:165 dce: ff c0 inc %eax __arch_swab32(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/swab.h:21 dd0: 0f c8 bswap %eax be32_add_cpu(): /home/pivanof/def_workspace/linux/include/linux/byteorder/generic.h:165 dd2: 41 89 45 44 mov %eax,0x44(%r13) hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:490 dd6: 41 8b 45 04 mov 0x4(%r13),%eax dda: 25 ff ff fe ff and $0xfffeffff,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:491 ddf: 0d 00 00 08 00 or $0x80000,%eax de4: 41 89 45 04 mov %eax,0x4(%r13) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:492 de8: e8 00 00 00 00 callq ded <hfsplus_fill_super+0x48d> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:494 ded: 48 83 7b 40 00 cmpq $0x0,0x40(%rbx) df2: 0f 85 5c ff ff ff jne d54 <hfsplus_fill_super+0x3f4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:495 df8: 48 8b bd 68 fd ff ff mov -0x298(%rbp),%rdi dff: e8 00 00 00 00 callq e04 <hfsplus_fill_super+0x4a4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:496 e04: 4c 89 e7 mov %r12,%rdi e07: be 00 40 00 00 mov $0x4000,%esi e0c: e8 00 00 00 00 callq e11 <hfsplus_fill_super+0x4b1> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:497 e11: 48 8d 95 b0 fd ff ff lea -0x250(%rbp),%rdx /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:496 e18: 48 89 43 40 mov %rax,0x40(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:497 e1c: 48 89 c1 mov %rax,%rcx e1f: 48 8b b5 60 fd ff ff mov -0x2a0(%rbp),%rsi e26: 48 8b 78 40 mov 0x40(%rax),%rdi e2a: e8 00 00 00 00 callq e2f <hfsplus_fill_super+0x4cf> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:499 e2f: 48 8b bd 68 fd ff ff mov -0x298(%rbp),%rdi e36: e8 00 00 00 00 callq e3b <hfsplus_fill_super+0x4db> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:501 e3b: 48 8b 7b 40 mov 0x40(%rbx),%rdi HFSPLUS_I(): /home/pivanof/def_workspace/linux/fs/hfsplus/hfsplus_fs.h:229 e3f: 48 8d 87 00 ff ff ff lea -0x100(%rdi),%rax set_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:63 e46: f0 80 88 d0 00 00 00 lock orb $0x2,0xd0(%rax) e4d: 02 mark_inode_dirty(): /home/pivanof/def_workspace/linux/include/linux/fs.h:1740 e4e: be 07 00 00 00 mov $0x7,%esi e53: e8 00 00 00 00 callq e58 <hfsplus_fill_super+0x4f8> e58: e9 f7 fe ff ff jmpq d54 <hfsplus_fill_super+0x3f4> e5d: 0f 1f 00 nopl (%rax) hfsplus_fill_super(): /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:518 e60: 48 8b 7b 40 mov 0x40(%rbx),%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:509 e64: 41 be f4 ff ff ff mov $0xfffffff4,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:518 e6a: e8 00 00 00 00 callq e6f <hfsplus_fill_super+0x50f> e6f: e9 a9 fd ff ff jmpq c1d <hfsplus_fill_super+0x2bd> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:536 e74: e8 00 00 00 00 callq e79 <hfsplus_fill_super+0x519> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:361 e79: 48 c7 c7 00 00 00 00 mov $0x0,%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:359 e80: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:361 e86: e8 00 00 00 00 callq e8b <hfsplus_fill_super+0x52b> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:346 e8b: 45 31 ff xor %r15d,%r15d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:362 e8e: e9 cc fb ff ff jmpq a5f <hfsplus_fill_super+0xff> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:369 e93: 48 c7 c7 00 00 00 00 mov $0x0,%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:359 e9a: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:369 ea0: e8 00 00 00 00 callq ea5 <hfsplus_fill_super+0x545> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:370 ea5: e9 b5 fb ff ff jmpq a5f <hfsplus_fill_super+0xff> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:449 eaa: 48 c7 c7 00 00 00 00 mov $0x0,%rdi eb1: 31 c0 xor %eax,%eax eb3: e8 00 00 00 00 callq eb8 <hfsplus_fill_super+0x558> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:451 eb8: e9 75 fd ff ff jmpq c32 <hfsplus_fill_super+0x2d2> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:458 ebd: 48 c7 c7 00 00 00 00 mov $0x0,%rdi ec4: 31 c0 xor %eax,%eax ec6: e8 00 00 00 00 callq ecb <hfsplus_fill_super+0x56b> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:459 ecb: 44 8b b5 60 fd ff ff mov -0x2a0(%rbp),%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:460 ed2: e9 52 fd ff ff jmpq c29 <hfsplus_fill_super+0x2c9> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:414 ed7: 48 c7 c7 00 00 00 00 mov $0x0,%rdi ede: 31 c0 xor %eax,%eax ee0: e8 00 00 00 00 callq ee5 <hfsplus_fill_super+0x585> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:418 ee5: 49 83 4c 24 50 01 orq $0x1,0x50(%r12) eeb: e9 89 fc ff ff jmpq b79 <hfsplus_fill_super+0x219> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:438 ef0: 48 c7 c7 00 00 00 00 mov $0x0,%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:433 ef7: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:438 efd: e8 00 00 00 00 callq f02 <hfsplus_fill_super+0x5a2> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:439 f02: e9 3d fd ff ff jmpq c44 <hfsplus_fill_super+0x2e4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:376 f07: 48 c7 c7 00 00 00 00 mov $0x0,%rdi f0e: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:359 f10: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:376 f16: e8 00 00 00 00 callq f1b <hfsplus_fill_super+0x5bb> f1b: e9 3f fb ff ff jmpq a5f <hfsplus_fill_super+0xff> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:443 f20: 48 c7 c7 00 00 00 00 mov $0x0,%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:433 f27: 41 be ea ff ff ff mov $0xffffffea,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:443 f2d: e8 00 00 00 00 callq f32 <hfsplus_fill_super+0x5d2> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:444 f32: e9 04 fd ff ff jmpq c3b <hfsplus_fill_super+0x2db> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:422 f37: 48 c7 c7 00 00 00 00 mov $0x0,%rdi f3e: 31 c0 xor %eax,%eax f40: e8 00 00 00 00 callq f45 <hfsplus_fill_super+0x5e5> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:423 f45: 49 83 4c 24 50 01 orq $0x1,0x50(%r12) f4b: e9 29 fc ff ff jmpq b79 <hfsplus_fill_super+0x219> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:405 f50: 48 c7 c7 00 00 00 00 mov $0x0,%rdi f57: 31 c0 xor %eax,%eax f59: e8 00 00 00 00 callq f5e <hfsplus_fill_super+0x5fe> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:406 f5e: e9 e1 fc ff ff jmpq c44 <hfsplus_fill_super+0x2e4> /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:475 f63: 41 89 c6 mov %eax,%r14d /home/pivanof/def_workspace/linux/fs/hfsplus/super.c:476 f66: e9 b2 fc ff ff jmpq c1d <hfsplus_fill_super+0x2bd> f6b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 0000000000000f70 <hfsplus_fill_defaults>: hfsplus_fill_defaults(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:49 f70: 55 push %rbp f71: 48 89 e5 mov %rsp,%rbp f74: 53 push %rbx f75: 48 83 ec 08 sub $0x8,%rsp f79: e8 00 00 00 00 callq f7e <hfsplus_fill_defaults+0xe> f7e: 48 89 fb mov %rdi,%rbx /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:50 f81: 48 85 ff test %rdi,%rdi f84: 74 5d je fe3 <hfsplus_fill_defaults+0x73> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:53 f86: c7 87 d8 00 00 00 3f movl $0x3f3f3f3f,0xd8(%rdi) f8d: 3f 3f 3f /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:54 f90: c7 87 dc 00 00 00 3f movl $0x3f3f3f3f,0xdc(%rdi) f97: 3f 3f 3f /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:55 f9a: e8 00 00 00 00 callq f9f <hfsplus_fill_defaults+0x2f> f9f: 66 89 83 e0 00 00 00 mov %ax,0xe0(%rbx) get_current(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/current.h:14 fa6: 65 48 8b 04 25 00 00 mov %gs:0x0,%rax fad: 00 00 hfsplus_fill_defaults(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:56 faf: 48 8b 90 58 04 00 00 mov 0x458(%rax),%rdx fb6: 8b 52 04 mov 0x4(%rdx),%edx fb9: 89 93 e4 00 00 00 mov %edx,0xe4(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:57 fbf: 48 8b 80 58 04 00 00 mov 0x458(%rax),%rax fc6: 8b 40 08 mov 0x8(%rax),%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:58 fc9: c7 83 ec 00 00 00 ff movl $0xffffffff,0xec(%rbx) fd0: ff ff ff /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:57 fd3: 89 83 e8 00 00 00 mov %eax,0xe8(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:59 fd9: c7 83 f0 00 00 00 ff movl $0xffffffff,0xf0(%rbx) fe0: ff ff ff /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:60 fe3: 48 83 c4 08 add $0x8,%rsp fe7: 5b pop %rbx fe8: c9 leaveq fe9: c3 retq fea: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 0000000000000ff0 <hfsplus_parse_options_remount>: hfsplus_parse_options_remount(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:72 ff0: 55 push %rbp ff1: 48 89 e5 mov %rsp,%rbp ff4: 53 push %rbx ff5: 48 83 ec 48 sub $0x48,%rsp ff9: e8 00 00 00 00 callq ffe <hfsplus_parse_options_remount+0xe> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:78 ffe: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:72 1000: 48 89 7d b8 mov %rdi,-0x48(%rbp) 1004: 48 89 f3 mov %rsi,%rbx /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:77 1007: 48 85 ff test %rdi,%rdi 100a: 74 46 je 1052 <hfsplus_parse_options_remount+0x62> 100c: 0f 1f 40 00 nopl 0x0(%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:80 1010: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 1017: 48 8d 7d b8 lea -0x48(%rbp),%rdi 101b: e8 00 00 00 00 callq 1020 <hfsplus_parse_options_remount+0x30> 1020: 48 85 c0 test %rax,%rax 1023: 74 2b je 1050 <hfsplus_parse_options_remount+0x60> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:81 1025: 80 38 00 cmpb $0x0,(%rax) 1028: 74 e6 je 1010 <hfsplus_parse_options_remount+0x20> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:84 102a: 48 8d 55 c0 lea -0x40(%rbp),%rdx 102e: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 1035: 48 89 c7 mov %rax,%rdi 1038: e8 00 00 00 00 callq 103d <hfsplus_parse_options_remount+0x4d> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:85 103d: 83 f8 0c cmp $0xc,%eax 1040: 75 ce jne 1010 <hfsplus_parse_options_remount+0x20> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:87 1042: c7 03 01 00 00 00 movl $0x1,(%rbx) 1048: eb c6 jmp 1010 <hfsplus_parse_options_remount+0x20> 104a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:94 1050: b0 01 mov $0x1,%al /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:95 1052: 48 83 c4 48 add $0x48,%rsp 1056: 5b pop %rbx 1057: c9 leaveq 1058: c3 retq 1059: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 0000000000001060 <hfsplus_parse_options>: hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:100 1060: 55 push %rbp 1061: 48 89 e5 mov %rsp,%rbp 1064: 41 56 push %r14 1066: 41 55 push %r13 1068: 41 54 push %r12 106a: 53 push %rbx 106b: 48 83 ec 50 sub $0x50,%rsp 106f: e8 00 00 00 00 callq 1074 <hfsplus_parse_options+0x14> 1074: 48 89 7d 98 mov %rdi,-0x68(%rbp) 1078: 48 89 f3 mov %rsi,%rbx /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:154 107b: 4c 8d ae f0 00 00 00 lea 0xf0(%rsi),%r13 /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:148 1082: 4c 8d a6 ec 00 00 00 lea 0xec(%rsi),%r12 /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:105 1089: 48 85 ff test %rdi,%rdi 108c: 74 5a je 10e8 <hfsplus_parse_options+0x88> 108e: 66 90 xchg %ax,%ax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:108 1090: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 1097: 48 8d 7d 98 lea -0x68(%rbp),%rdi 109b: e8 00 00 00 00 callq 10a0 <hfsplus_parse_options+0x40> 10a0: 48 85 c0 test %rax,%rax 10a3: 74 43 je 10e8 <hfsplus_parse_options+0x88> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:109 10a5: 80 38 00 cmpb $0x0,(%rax) 10a8: 74 e6 je 1090 <hfsplus_parse_options+0x30> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:112 10aa: 48 8d 55 a0 lea -0x60(%rbp),%rdx 10ae: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 10b5: 48 89 c7 mov %rax,%rdi 10b8: e8 00 00 00 00 callq 10bd <hfsplus_parse_options+0x5d> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:113 10bd: 83 f8 0c cmp $0xc,%eax 10c0: 76 16 jbe 10d8 <hfsplus_parse_options+0x78> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:192 10c2: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:207 10c5: 48 83 c4 50 add $0x50,%rsp 10c9: 44 89 e0 mov %r12d,%eax 10cc: 5b pop %rbx 10cd: 41 5c pop %r12 10cf: 41 5d pop %r13 10d1: 41 5e pop %r14 10d3: c9 leaveq 10d4: c3 retq 10d5: 0f 1f 00 nopl (%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:113 10d8: 89 c0 mov %eax,%eax 10da: ff 24 c5 00 00 00 00 jmpq *0x0(,%rax,8) 10e1: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:206 10e8: 41 bc 01 00 00 00 mov $0x1,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:197 10ee: 48 83 7b 48 00 cmpq $0x0,0x48(%rbx) 10f3: 75 d0 jne 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:199 10f5: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 10fc: e8 00 00 00 00 callq 1101 <hfsplus_parse_options+0xa1> 1101: 48 89 43 48 mov %rax,0x48(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:200 1105: 48 85 c0 test %rax,%rax 1108: 75 bb jne 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:201 110a: e8 00 00 00 00 callq 110f <hfsplus_parse_options+0xaf> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:117 110f: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:201 1112: 48 89 43 48 mov %rax,0x48(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:117 1116: 48 85 c0 test %rax,%rax 1119: 41 0f 95 c4 setne %r12b 111d: eb a6 jmp 10c5 <hfsplus_parse_options+0x65> 111f: 90 nop set_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:63 1120: f0 80 8b f8 00 00 00 lock orb $0x20,0xf8(%rbx) 1127: 20 1128: e9 63 ff ff ff jmpq 1090 <hfsplus_parse_options+0x30> 112d: 0f 1f 00 nopl (%rax) clear_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:101 1130: f0 80 a3 f8 00 00 00 lock andb $0xdf,0xf8(%rbx) 1137: df 1138: e9 53 ff ff ff jmpq 1090 <hfsplus_parse_options+0x30> 113d: 0f 1f 00 nopl (%rax) 1140: f0 80 a3 f8 00 00 00 lock andb $0xfd,0xf8(%rbx) 1147: fd 1148: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 114f: 00 1150: e9 3b ff ff ff jmpq 1090 <hfsplus_parse_options+0x30> 1155: 0f 1f 00 nopl (%rax) set_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:63 1158: f0 80 8b f8 00 00 00 lock orb $0x2,0xf8(%rbx) 115f: 02 1160: e9 2b ff ff ff jmpq 1090 <hfsplus_parse_options+0x30> 1165: 0f 1f 00 nopl (%rax) hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:160 1168: 48 83 7b 48 00 cmpq $0x0,0x48(%rbx) 116d: 0f 1f 00 nopl (%rax) 1170: 0f 85 13 02 00 00 jne 1389 <hfsplus_parse_options+0x329> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:164 1176: 48 8d 7d a0 lea -0x60(%rbp),%rdi 117a: e8 00 00 00 00 callq 117f <hfsplus_parse_options+0x11f> 117f: 49 89 c6 mov %rax,%r14 /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:165 1182: 48 85 c0 test %rax,%rax 1185: 0f 84 7a 01 00 00 je 1305 <hfsplus_parse_options+0x2a5> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:166 118b: 48 89 c7 mov %rax,%rdi 118e: e8 00 00 00 00 callq 1193 <hfsplus_parse_options+0x133> 1193: 48 89 43 48 mov %rax,0x48(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:167 1197: 48 85 c0 test %rax,%rax 119a: 0f 84 ca 01 00 00 je 136a <hfsplus_parse_options+0x30a> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:174 11a0: 4c 89 f7 mov %r14,%rdi 11a3: e8 00 00 00 00 callq 11a8 <hfsplus_parse_options+0x148> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:175 11a8: e9 e3 fe ff ff jmpq 1090 <hfsplus_parse_options+0x30> 11ad: 0f 1f 00 nopl (%rax) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:154 11b0: 4c 89 ee mov %r13,%rsi 11b3: 48 8d 7d a0 lea -0x60(%rbp),%rdi 11b7: e8 00 00 00 00 callq 11bc <hfsplus_parse_options+0x15c> 11bc: 85 c0 test %eax,%eax 11be: 0f 84 cc fe ff ff je 1090 <hfsplus_parse_options+0x30> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:155 11c4: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 11cb: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:156 11cd: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:155 11d0: e8 00 00 00 00 callq 11d5 <hfsplus_parse_options+0x175> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:156 11d5: e9 eb fe ff ff jmpq 10c5 <hfsplus_parse_options+0x65> 11da: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:148 11e0: 4c 89 e6 mov %r12,%rsi 11e3: 48 8d 7d a0 lea -0x60(%rbp),%rdi 11e7: e8 00 00 00 00 callq 11ec <hfsplus_parse_options+0x18c> 11ec: 85 c0 test %eax,%eax 11ee: 0f 84 9c fe ff ff je 1090 <hfsplus_parse_options+0x30> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:149 11f4: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 11fb: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:150 11fd: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:149 1200: e8 00 00 00 00 callq 1205 <hfsplus_parse_options+0x1a5> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:150 1205: e9 bb fe ff ff jmpq 10c5 <hfsplus_parse_options+0x65> 120a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:141 1210: 48 8d 75 dc lea -0x24(%rbp),%rsi 1214: 48 8d 7d a0 lea -0x60(%rbp),%rdi 1218: e8 00 00 00 00 callq 121d <hfsplus_parse_options+0x1bd> 121d: 85 c0 test %eax,%eax 121f: 0f 85 03 01 00 00 jne 1328 <hfsplus_parse_options+0x2c8> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:145 1225: 8b 45 dc mov -0x24(%rbp),%eax 1228: 89 83 e8 00 00 00 mov %eax,0xe8(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:146 122e: e9 5d fe ff ff jmpq 1090 <hfsplus_parse_options+0x30> 1233: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:134 1238: 48 8d 75 dc lea -0x24(%rbp),%rsi 123c: 48 8d 7d a0 lea -0x60(%rbp),%rdi 1240: e8 00 00 00 00 callq 1245 <hfsplus_parse_options+0x1e5> 1245: 85 c0 test %eax,%eax 1247: 0f 85 f1 00 00 00 jne 133e <hfsplus_parse_options+0x2de> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:138 124d: 8b 45 dc mov -0x24(%rbp),%eax 1250: 89 83 e4 00 00 00 mov %eax,0xe4(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:139 1256: e9 35 fe ff ff jmpq 1090 <hfsplus_parse_options+0x30> 125b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:127 1260: 48 8d 75 dc lea -0x24(%rbp),%rsi 1264: 48 8d 7d a0 lea -0x60(%rbp),%rdi 1268: e8 00 00 00 00 callq 126d <hfsplus_parse_options+0x20d> 126d: 85 c0 test %eax,%eax 126f: 0f 85 df 00 00 00 jne 1354 <hfsplus_parse_options+0x2f4> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:131 1275: 8b 45 dc mov -0x24(%rbp),%eax 1278: 66 89 83 e0 00 00 00 mov %ax,0xe0(%rbx) /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:132 127f: e9 0c fe ff ff jmpq 1090 <hfsplus_parse_options+0x30> 1284: 0f 1f 40 00 nopl 0x0(%rax) match_fourchar(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:65 1288: 48 8b 55 a0 mov -0x60(%rbp),%rdx 128c: 48 8b 45 a8 mov -0x58(%rbp),%rax 1290: 48 29 d0 sub %rdx,%rax 1293: 48 83 f8 04 cmp $0x4,%rax 1297: 0f 84 7e 00 00 00 je 131b <hfsplus_parse_options+0x2bb> hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:123 129d: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:122 12a0: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 12a7: 31 c0 xor %eax,%eax 12a9: e8 00 00 00 00 callq 12ae <hfsplus_parse_options+0x24e> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:207 12ae: 48 83 c4 50 add $0x50,%rsp 12b2: 44 89 e0 mov %r12d,%eax 12b5: 5b pop %rbx 12b6: 41 5c pop %r12 12b8: 41 5d pop %r13 12ba: 41 5e pop %r14 12bc: c9 leaveq 12bd: c3 retq 12be: 66 90 xchg %ax,%ax match_fourchar(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:65 12c0: 48 8b 55 a0 mov -0x60(%rbp),%rdx 12c4: 48 8b 45 a8 mov -0x58(%rbp),%rax 12c8: 48 29 d0 sub %rdx,%rax 12cb: 48 83 f8 04 cmp $0x4,%rax 12cf: 74 3d je 130e <hfsplus_parse_options+0x2ae> hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:117 12d1: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:116 12d4: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 12db: 31 c0 xor %eax,%eax 12dd: e8 00 00 00 00 callq 12e2 <hfsplus_parse_options+0x282> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:207 12e2: 48 83 c4 50 add $0x50,%rsp 12e6: 44 89 e0 mov %r12d,%eax 12e9: 5b pop %rbx 12ea: 41 5c pop %r12 12ec: 41 5d pop %r13 12ee: 41 5e pop %r14 12f0: c9 leaveq 12f1: c3 retq 12f2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) set_bit(): /home/pivanof/def_workspace/linux/arch/x86/include/asm/bitops.h:63 12f8: f0 80 8b f8 00 00 00 lock orb $0x4,0xf8(%rbx) 12ff: 04 1300: e9 8b fd ff ff jmpq 1090 <hfsplus_parse_options+0x30> hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:165 1305: 48 8b 43 48 mov 0x48(%rbx),%rax 1309: e9 89 fe ff ff jmpq 1197 <hfsplus_parse_options+0x137> match_fourchar(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:67 130e: 8b 02 mov (%rdx),%eax 1310: 89 83 d8 00 00 00 mov %eax,0xd8(%rbx) 1316: e9 75 fd ff ff jmpq 1090 <hfsplus_parse_options+0x30> 131b: 8b 02 mov (%rdx),%eax 131d: 89 83 dc 00 00 00 mov %eax,0xdc(%rbx) 1323: e9 68 fd ff ff jmpq 1090 <hfsplus_parse_options+0x30> hfsplus_parse_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:142 1328: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 132f: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:143 1331: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:142 1334: e8 00 00 00 00 callq 1339 <hfsplus_parse_options+0x2d9> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:143 1339: e9 87 fd ff ff jmpq 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:135 133e: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 1345: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:136 1347: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:135 134a: e8 00 00 00 00 callq 134f <hfsplus_parse_options+0x2ef> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:136 134f: e9 71 fd ff ff jmpq 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:128 1354: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 135b: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:129 135d: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:128 1360: e8 00 00 00 00 callq 1365 <hfsplus_parse_options+0x305> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:129 1365: e9 5b fd ff ff jmpq 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:168 136a: 4c 89 f6 mov %r14,%rsi 136d: 48 c7 c7 00 00 00 00 mov $0x0,%rdi /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:172 1374: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:168 1377: e8 00 00 00 00 callq 137c <hfsplus_parse_options+0x31c> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:171 137c: 4c 89 f7 mov %r14,%rdi 137f: e8 00 00 00 00 callq 1384 <hfsplus_parse_options+0x324> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:172 1384: e9 3c fd ff ff jmpq 10c5 <hfsplus_parse_options+0x65> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:161 1389: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 1390: 31 c0 xor %eax,%eax /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:162 1392: 45 31 e4 xor %r12d,%r12d /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:161 1395: e8 00 00 00 00 callq 139a <hfsplus_parse_options+0x33a> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:162 139a: e9 26 fd ff ff jmpq 10c5 <hfsplus_parse_options+0x65> 139f: 90 nop 00000000000013a0 <hfsplus_show_options>: hfsplus_show_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:210 13a0: 55 push %rbp 13a1: 48 89 e5 mov %rsp,%rbp 13a4: 41 54 push %r12 13a6: 53 push %rbx 13a7: e8 00 00 00 00 callq 13ac <hfsplus_show_options+0xc> HFSPLUS_SB(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:230 13ac: 48 8b 46 28 mov 0x28(%rsi),%rax hfsplus_show_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:210 13b0: 49 89 fc mov %rdi,%r12 HFSPLUS_SB(): /home/pivanof/def_workspace/linux/fs/hfsplus/hfsplus_fs.h:169 13b3: 48 8b 98 b0 02 00 00 mov 0x2b0(%rax),%rbx hfsplus_show_options(): /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:213 13ba: 81 bb d8 00 00 00 3f cmpl $0x3f3f3f3f,0xd8(%rbx) 13c1: 3f 3f 3f 13c4: 74 15 je 13db <hfsplus_show_options+0x3b> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:214 13c6: 48 8d 93 d8 00 00 00 lea 0xd8(%rbx),%rdx 13cd: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 13d4: 31 c0 xor %eax,%eax 13d6: e8 00 00 00 00 callq 13db <hfsplus_show_options+0x3b> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:215 13db: 81 bb dc 00 00 00 3f cmpl $0x3f3f3f3f,0xdc(%rbx) 13e2: 3f 3f 3f 13e5: 74 18 je 13ff <hfsplus_show_options+0x5f> /home/pivanof/def_workspace/linux/fs/hfsplus/options.c:216 13e7: 48 8d 93 dc 00 00 00 lea 0xdc(%rbx),%rdx 13ee: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 13f5: 4c 89 e7 mov %r12,%rdi 13f8: 31 c0 xor %eax,%eax ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 4:37 ` Pavel Ivanov @ 2011-09-03 6:57 ` Hin-Tak Leung 2011-09-03 20:52 ` Pavel Ivanov 0 siblings, 1 reply; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-03 6:57 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > On Fri, Sep 2, 2011 at 11:59 PM, > Hin-Tak Leung <hintak_leung@yahoo.co.uk> > wrote: > >> With kernel 3.1.0-rc4 any attempt to connect iPod > to USB > >> leads to > >> kernel oops. I'd say that stacktrace of the oops > is pretty > >> much random > >> and not related to HFS. But I was able to get > useful info > >> from it when > >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this > case I > >> don't get > >> oops but the following instead: > > > > There are a few hfsplus related changes to do > protection against invalid data like this, but may be there > are more. It would be useful to have the output from your > > objdump -l -d hfsplus.ko | grep -A 1000 > '<hfsplus_fill_super>' > > (the -l gives line numbers against the kernel tree, so > would be useful if you run this against the ko there...) > > Output of this command is in attachment. That's interesting. You said "hfs: filesystem size too large." always appears twice (with kernel 3.1-rc4) before it oops. And in your 2.6.38.11 kernel, you had "hfs: unable to find HFS+ superblock" twice. The oops place is the "kfree(sbi->s_backup_vhdr)" in line 529 in fs/hfsplus/super.c: 527: out_free_vhdr: 528: kfree(sbi->s_vhdr); 529: kfree(sbi->s_backup_vhdr); It would appear the s_backup_vhdr is somehow garbage but that was not caught in the 3.1-rc4 version of hfsplus_read_wrapper() ; it was caught by the 2.6.38.11 version of hfsplus_read_wrapper(). hfsplus_read_wrapper() was changed in the 2.6.39/3.0 time frame by this: commit 52399b171dfaea02b6944cd6feba49b624147126 Author: Christoph Hellwig <hch@tuxera.com> Date: Tue Nov 23 14:37:47 2010 +0100 hfsplus: use raw bio access for the volume headers That's code I don't quite understand (I worked on the hfsplus journal code recently, supposedly mentoring for that GSoC project). If you are happy enough to do a bit of experimenting, can you try putting a "if(sbi->s_backup_vhdr)" before line 529? Also it is curious why it wasn't caught in wrapper.c arond 229 to 236 ending with: "if (sbi->s_backup_vhdr->signature != sbi->s_vhdr->signature)" The file system too large comes from line 402 in super.c: ----------------------- err = generic_check_addressable(sbi->alloc_blksz_shift, sbi->total_blocks); if (err) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; ----------------------- So it might be interesting to see what is too large... try changing that to: printk(KERN_ERR "hfs: filesystem size too large blksz_shift=%d, total_blocks=%d\n", sbi->alloc_blksz_shift, sbi->total_blocks); ? It is a 42GB image - if it were smaller I would suggest dd'ing that and upload it somewhere to check... ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 6:57 ` Hin-Tak Leung @ 2011-09-03 20:52 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-03 20:52 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel Hin-Tak, "if(sbi->s_backup_vhdr)" as you suggested didn't help. But I made another change. I made fs/hfsplus/super.c to look like this near the line 529: out_free_vhdr: printk(KERN_ERR "hfs: sbi->s_vhdr = %p, sbi->s_backup_vhdr = %p\n", sbi->s_vhdr, sbi->s_backup_vhdr); kfree(sbi->s_vhdr); kfree(sbi->s_backup_vhdr); And here's what I see after connecting an iPod: [ 92.549197] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 [ 92.635714] hfs: sbi->s_vhdr = ffff88013703a690, sbi->s_backup_vhdr = ffff88013703e268 [ 92.730543] ============================================================================= [ 92.828425] BUG kmalloc-4096: Invalid object pointer 0xffff88013703a690 ... [ 93.213890] ============================================================================= [ 93.311834] BUG kmalloc-4096: Invalid object pointer 0xffff88013703e268 ... [ 93.868618] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 [ 93.955327] hfs: sbi->s_vhdr = ffff8801343c37d8, sbi->s_backup_vhdr = ffff8801343c5120 [ 94.050133] ============================================================================= [ 94.148026] BUG kmalloc-4096: Invalid object pointer 0xffff8801343c37d8 ... [ 94.533895] ============================================================================= [ 94.631746] BUG kmalloc-4096: Invalid object pointer 0xffff8801343c5120 So these 2 pointers are exactly what causing the trouble. Pavel On Sat, Sep 3, 2011 at 2:57 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: > --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > >> On Fri, Sep 2, 2011 at 11:59 PM, >> Hin-Tak Leung <hintak_leung@yahoo.co.uk> >> wrote: >> >> With kernel 3.1.0-rc4 any attempt to connect iPod >> to USB >> >> leads to >> >> kernel oops. I'd say that stacktrace of the oops >> is pretty >> >> much random >> >> and not related to HFS. But I was able to get >> useful info >> >> from it when >> >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this >> case I >> >> don't get >> >> oops but the following instead: >> > >> > There are a few hfsplus related changes to do >> protection against invalid data like this, but may be there >> are more. It would be useful to have the output from your >> > objdump -l -d hfsplus.ko | grep -A 1000 >> '<hfsplus_fill_super>' >> > (the -l gives line numbers against the kernel tree, so >> would be useful if you run this against the ko there...) >> >> Output of this command is in attachment. > > That's interesting. You said "hfs: filesystem size too large." always appears twice (with kernel 3.1-rc4) before it oops. And in your 2.6.38.11 kernel, you had "hfs: unable to find HFS+ superblock" twice. > > The oops place is the "kfree(sbi->s_backup_vhdr)" in line 529 in fs/hfsplus/super.c: > > 527: out_free_vhdr: > 528: kfree(sbi->s_vhdr); > 529: kfree(sbi->s_backup_vhdr); > > It would appear the s_backup_vhdr is somehow garbage but that was not caught in the 3.1-rc4 version of hfsplus_read_wrapper() ; it was caught by the 2.6.38.11 version of hfsplus_read_wrapper(). hfsplus_read_wrapper() was changed in the 2.6.39/3.0 time frame by this: > > commit 52399b171dfaea02b6944cd6feba49b624147126 > Author: Christoph Hellwig <hch@tuxera.com> > Date: Tue Nov 23 14:37:47 2010 +0100 > > hfsplus: use raw bio access for the volume headers > > That's code I don't quite understand (I worked on the hfsplus journal code recently, supposedly mentoring for that GSoC project). > > If you are happy enough to do a bit of experimenting, can you try putting a > "if(sbi->s_backup_vhdr)" before line 529? > > Also it is curious why it wasn't caught in wrapper.c arond 229 to 236 ending with: > "if (sbi->s_backup_vhdr->signature != sbi->s_vhdr->signature)" > > > The file system too large comes from line 402 in super.c: > ----------------------- > err = generic_check_addressable(sbi->alloc_blksz_shift, > sbi->total_blocks); > if (err) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > > ----------------------- > So it might be interesting to see what is too large... try changing that to: > > printk(KERN_ERR "hfs: filesystem size too large blksz_shift=%d, total_blocks=%d\n", sbi->alloc_blksz_shift, sbi->total_blocks); > > ? > > It is a 42GB image - if it were smaller I would suggest dd'ing that and upload it somewhere to check... > > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-03 20:52 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-03 20:52 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel Hin-Tak, "if(sbi->s_backup_vhdr)" as you suggested didn't help. But I made another change. I made fs/hfsplus/super.c to look like this near the line 529: out_free_vhdr: printk(KERN_ERR "hfs: sbi->s_vhdr = %p, sbi->s_backup_vhdr = %p\n", sbi->s_vhdr, sbi->s_backup_vhdr); kfree(sbi->s_vhdr); kfree(sbi->s_backup_vhdr); And here's what I see after connecting an iPod: [ 92.549197] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 [ 92.635714] hfs: sbi->s_vhdr = ffff88013703a690, sbi->s_backup_vhdr = ffff88013703e268 [ 92.730543] ============================================================================= [ 92.828425] BUG kmalloc-4096: Invalid object pointer 0xffff88013703a690 ... [ 93.213890] ============================================================================= [ 93.311834] BUG kmalloc-4096: Invalid object pointer 0xffff88013703e268 ... [ 93.868618] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 [ 93.955327] hfs: sbi->s_vhdr = ffff8801343c37d8, sbi->s_backup_vhdr = ffff8801343c5120 [ 94.050133] ============================================================================= [ 94.148026] BUG kmalloc-4096: Invalid object pointer 0xffff8801343c37d8 ... [ 94.533895] ============================================================================= [ 94.631746] BUG kmalloc-4096: Invalid object pointer 0xffff8801343c5120 So these 2 pointers are exactly what causing the trouble. Pavel On Sat, Sep 3, 2011 at 2:57 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: > --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > >> On Fri, Sep 2, 2011 at 11:59 PM, >> Hin-Tak Leung <hintak_leung@yahoo.co.uk> >> wrote: >> >> With kernel 3.1.0-rc4 any attempt to connect iPod >> to USB >> >> leads to >> >> kernel oops. I'd say that stacktrace of the oops >> is pretty >> >> much random >> >> and not related to HFS. But I was able to get >> useful info >> >> from it when >> >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. In this >> case I >> >> don't get >> >> oops but the following instead: >> > >> > There are a few hfsplus related changes to do >> protection against invalid data like this, but may be there >> are more. It would be useful to have the output from your >> > objdump -l -d hfsplus.ko | grep -A 1000 >> '<hfsplus_fill_super>' >> > (the -l gives line numbers against the kernel tree, so >> would be useful if you run this against the ko there...) >> >> Output of this command is in attachment. > > That's interesting. You said "hfs: filesystem size too large." always appears twice (with kernel 3.1-rc4) before it oops. And in your 2.6.38.11 kernel, you had "hfs: unable to find HFS+ superblock" twice. > > The oops place is the "kfree(sbi->s_backup_vhdr)" in line 529 in fs/hfsplus/super.c: > > 527: out_free_vhdr: > 528: kfree(sbi->s_vhdr); > 529: kfree(sbi->s_backup_vhdr); > > It would appear the s_backup_vhdr is somehow garbage but that was not caught in the 3.1-rc4 version of hfsplus_read_wrapper() ; it was caught by the 2.6.38.11 version of hfsplus_read_wrapper(). hfsplus_read_wrapper() was changed in the 2.6.39/3.0 time frame by this: > > commit 52399b171dfaea02b6944cd6feba49b624147126 > Author: Christoph Hellwig <hch@tuxera.com> > Date: Tue Nov 23 14:37:47 2010 +0100 > > hfsplus: use raw bio access for the volume headers > > That's code I don't quite understand (I worked on the hfsplus journal code recently, supposedly mentoring for that GSoC project). > > If you are happy enough to do a bit of experimenting, can you try putting a > "if(sbi->s_backup_vhdr)" before line 529? > > Also it is curious why it wasn't caught in wrapper.c arond 229 to 236 ending with: > "if (sbi->s_backup_vhdr->signature != sbi->s_vhdr->signature)" > > > The file system too large comes from line 402 in super.c: > ----------------------- > err = generic_check_addressable(sbi->alloc_blksz_shift, > sbi->total_blocks); > if (err) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > > ----------------------- > So it might be interesting to see what is too large... try changing that to: > > printk(KERN_ERR "hfs: filesystem size too large blksz_shift=%d, total_blocks=%d\n", sbi->alloc_blksz_shift, sbi->total_blocks); > > ? > > It is a 42GB image - if it were smaller I would suggest dd'ing that and upload it somewhere to check... > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 20:52 ` Pavel Ivanov @ 2011-09-03 23:35 ` Hin-Tak Leung -1 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-03 23:35 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > Hin-Tak, > > "if(sbi->s_backup_vhdr)" as you suggested didn't help. > But I made > another change. I made fs/hfsplus/super.c to look like this > near the > line 529: > > out_free_vhdr: > printk(KERN_ERR "hfs: sbi->s_vhdr = > %p, sbi->s_backup_vhdr = %p\n", > sbi->s_vhdr, sbi->s_backup_vhdr); > kfree(sbi->s_vhdr); > kfree(sbi->s_backup_vhdr); > > And here's what I see after connecting an iPod: > > [ 92.549197] hfs: filesystem size too > large blksz_shift=14, > total_blocks=486494 > [ 92.635714] hfs: sbi->s_vhdr = > ffff88013703a690, sbi->s_backup_vhdr > = ffff88013703e268 > [ 92.730543] > ============================================================================= > [ 92.828425] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703a690 > ... > [ 93.213890] > ============================================================================= > [ 93.311834] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703e268 > ... > [ 93.868618] hfs: filesystem size too > large blksz_shift=14, > total_blocks=486494 > [ 93.955327] hfs: sbi->s_vhdr = > ffff8801343c37d8, sbi->s_backup_vhdr > = ffff8801343c5120 > [ 94.050133] > ============================================================================= > [ 94.148026] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c37d8 > ... > [ 94.533895] > ============================================================================= > [ 94.631746] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c5120 > > > So these 2 pointers are exactly what causing the trouble. This is interesting... so it would appear that hfsplus_read_wrapper() isn't working correctly, but enough of correct information to pass checks. I just re-read your e-mail and your device has a logical block size of 4096 bytes, whereas most of the hfsplus code uses a block size of 512... you will need to look into hfsplus_submit_bio(), which is in the same file wrapper.c. It is going to be difficult to do anything without the actual device and 8GB is too large to be send around. Assuming it is mostly music/media and there isn't too much stuff which is too confident/private, can I ask you to send me say, the first few MB of the disk? I guess something like this: dd if=/dev/sdb of=diskfile-sdb ibs=4096 count=512 dd if=/dev/sdb1 of=diskfile-sdb1 ibs=4096 count=512 dd if=/dev/sdb2 of=diskfile-sdb2 ibs=4096 count=512 should copy the first 2MB of the disk itself and the two partitions. I hope that's enough to have a look around. Be really careful with dd though - it could do some serious damage if not carefully used. > On Sat, Sep 3, 2011 at 2:57 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> > wrote: > > --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> > wrote: > > > >> On Fri, Sep 2, 2011 at 11:59 PM, > >> Hin-Tak Leung <hintak_leung@yahoo.co.uk> > >> wrote: > >> >> With kernel 3.1.0-rc4 any attempt to > connect iPod > >> to USB > >> >> leads to > >> >> kernel oops. I'd say that stacktrace of > the oops > >> is pretty > >> >> much random > >> >> and not related to HFS. But I was able to > get > >> useful info > >> >> from it when > >> >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. > In this > >> case I > >> >> don't get > >> >> oops but the following instead: > >> > > >> > There are a few hfsplus related changes to > do > >> protection against invalid data like this, but may > be there > >> are more. It would be useful to have the output > from your > >> > objdump -l -d hfsplus.ko | grep -A 1000 > >> '<hfsplus_fill_super>' > >> > (the -l gives line numbers against the kernel > tree, so > >> would be useful if you run this against the ko > there...) > >> > >> Output of this command is in attachment. > > > > That's interesting. You said "hfs: filesystem size too > large." always appears twice (with kernel 3.1-rc4) before it > oops. And in your 2.6.38.11 kernel, you had "hfs: unable to > find HFS+ superblock" twice. > > > > The oops place is the "kfree(sbi->s_backup_vhdr)" > in line 529 in fs/hfsplus/super.c: > > > > 527: out_free_vhdr: > > 528: kfree(sbi->s_vhdr); > > 529: kfree(sbi->s_backup_vhdr); > > > > It would appear the s_backup_vhdr is somehow garbage > but that was not caught in the 3.1-rc4 version of > hfsplus_read_wrapper() ; it was caught by the 2.6.38.11 > version of hfsplus_read_wrapper(). hfsplus_read_wrapper() > was changed in the 2.6.39/3.0 time frame by this: > > > > commit 52399b171dfaea02b6944cd6feba49b624147126 > > Author: Christoph Hellwig <hch@tuxera.com> > > Date: Tue Nov 23 14:37:47 2010 +0100 > > > > hfsplus: use raw bio access for the volume > headers > > > > That's code I don't quite understand (I worked on the > hfsplus journal code recently, supposedly mentoring for that > GSoC project). > > > > If you are happy enough to do a bit of experimenting, > can you try putting a > > "if(sbi->s_backup_vhdr)" before line 529? > > > > Also it is curious why it wasn't caught in wrapper.c > arond 229 to 236 ending with: > > "if (sbi->s_backup_vhdr->signature != > sbi->s_vhdr->signature)" > > > > > > The file system too large comes from line 402 in > super.c: > > ----------------------- > > err = > generic_check_addressable(sbi->alloc_blksz_shift, > > > sbi->total_blocks); > > if (err) { > > printk(KERN_ERR "hfs: > filesystem size too large.\n"); > > goto out_free_vhdr; > > > > ----------------------- > > So it might be interesting to see what is too large... > try changing that to: > > > > printk(KERN_ERR "hfs: filesystem size too large > blksz_shift=%d, total_blocks=%d\n", > sbi->alloc_blksz_shift, sbi->total_blocks); > > > > ? > > > > It is a 42GB image - if it were smaller I would > suggest dd'ing that and upload it somewhere to check... > > > > > > > > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-03 23:35 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-03 23:35 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > Hin-Tak, > > "if(sbi->s_backup_vhdr)" as you suggested didn't help. > But I made > another change. I made fs/hfsplus/super.c to look like this > near the > line 529: > > out_free_vhdr: > printk(KERN_ERR "hfs: sbi->s_vhdr = > %p, sbi->s_backup_vhdr = %p\n", > sbi->s_vhdr, sbi->s_backup_vhdr); > kfree(sbi->s_vhdr); > kfree(sbi->s_backup_vhdr); > > And here's what I see after connecting an iPod: > > [ 92.549197] hfs: filesystem size too > large blksz_shift=14, > total_blocks=486494 > [ 92.635714] hfs: sbi->s_vhdr = > ffff88013703a690, sbi->s_backup_vhdr > = ffff88013703e268 > [ 92.730543] > ============================================================================= > [ 92.828425] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703a690 > ... > [ 93.213890] > ============================================================================= > [ 93.311834] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703e268 > ... > [ 93.868618] hfs: filesystem size too > large blksz_shift=14, > total_blocks=486494 > [ 93.955327] hfs: sbi->s_vhdr = > ffff8801343c37d8, sbi->s_backup_vhdr > = ffff8801343c5120 > [ 94.050133] > ============================================================================= > [ 94.148026] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c37d8 > ... > [ 94.533895] > ============================================================================= > [ 94.631746] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c5120 > > > So these 2 pointers are exactly what causing the trouble. This is interesting... so it would appear that hfsplus_read_wrapper() isn't working correctly, but enough of correct information to pass checks. I just re-read your e-mail and your device has a logical block size of 4096 bytes, whereas most of the hfsplus code uses a block size of 512... you will need to look into hfsplus_submit_bio(), which is in the same file wrapper.c. It is going to be difficult to do anything without the actual device and 8GB is too large to be send around. Assuming it is mostly music/media and there isn't too much stuff which is too confident/private, can I ask you to send me say, the first few MB of the disk? I guess something like this: dd if=/dev/sdb of=diskfile-sdb ibs=4096 count=512 dd if=/dev/sdb1 of=diskfile-sdb1 ibs=4096 count=512 dd if=/dev/sdb2 of=diskfile-sdb2 ibs=4096 count=512 should copy the first 2MB of the disk itself and the two partitions. I hope that's enough to have a look around. Be really careful with dd though - it could do some serious damage if not carefully used. > On Sat, Sep 3, 2011 at 2:57 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> > wrote: > > --- On Sat, 3/9/11, Pavel Ivanov <paivanof@gmail.com> > wrote: > > > >> On Fri, Sep 2, 2011 at 11:59 PM, > >> Hin-Tak Leung <hintak_leung@yahoo.co.uk> > >> wrote: > >> >> With kernel 3.1.0-rc4 any attempt to > connect iPod > >> to USB > >> >> leads to > >> >> kernel oops. I'd say that stacktrace of > the oops > >> is pretty > >> >> much random > >> >> and not related to HFS. But I was able to > get > >> useful info > >> >> from it when > >> >> I recompiled with CONFIG_SLUB_DEBUG_ON=y. > In this > >> case I > >> >> don't get > >> >> oops but the following instead: > >> > > >> > There are a few hfsplus related changes to > do > >> protection against invalid data like this, but may > be there > >> are more. It would be useful to have the output > from your > >> > objdump -l -d hfsplus.ko | grep -A 1000 > >> '<hfsplus_fill_super>' > >> > (the -l gives line numbers against the kernel > tree, so > >> would be useful if you run this against the ko > there...) > >> > >> Output of this command is in attachment. > > > > That's interesting. You said "hfs: filesystem size too > large." always appears twice (with kernel 3.1-rc4) before it > oops. And in your 2.6.38.11 kernel, you had "hfs: unable to > find HFS+ superblock" twice. > > > > The oops place is the "kfree(sbi->s_backup_vhdr)" > in line 529 in fs/hfsplus/super.c: > > > > 527: out_free_vhdr: > > 528: kfree(sbi->s_vhdr); > > 529: kfree(sbi->s_backup_vhdr); > > > > It would appear the s_backup_vhdr is somehow garbage > but that was not caught in the 3.1-rc4 version of > hfsplus_read_wrapper() ; it was caught by the 2.6.38.11 > version of hfsplus_read_wrapper(). hfsplus_read_wrapper() > was changed in the 2.6.39/3.0 time frame by this: > > > > commit 52399b171dfaea02b6944cd6feba49b624147126 > > Author: Christoph Hellwig <hch@tuxera.com> > > Date: Tue Nov 23 14:37:47 2010 +0100 > > > > hfsplus: use raw bio access for the volume > headers > > > > That's code I don't quite understand (I worked on the > hfsplus journal code recently, supposedly mentoring for that > GSoC project). > > > > If you are happy enough to do a bit of experimenting, > can you try putting a > > "if(sbi->s_backup_vhdr)" before line 529? > > > > Also it is curious why it wasn't caught in wrapper.c > arond 229 to 236 ending with: > > "if (sbi->s_backup_vhdr->signature != > sbi->s_vhdr->signature)" > > > > > > The file system too large comes from line 402 in > super.c: > > ----------------------- > > err = > generic_check_addressable(sbi->alloc_blksz_shift, > > > sbi->total_blocks); > > if (err) { > > printk(KERN_ERR "hfs: > filesystem size too large.\n"); > > goto out_free_vhdr; > > > > ----------------------- > > So it might be interesting to see what is too large... > try changing that to: > > > > printk(KERN_ERR "hfs: filesystem size too large > blksz_shift=%d, total_blocks=%d\n", > sbi->alloc_blksz_shift, sbi->total_blocks); > > > > ? > > > > It is a 42GB image - if it were smaller I would > suggest dd'ing that and upload it somewhere to check... > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 23:35 ` Hin-Tak Leung @ 2011-09-03 23:59 ` Pavel Ivanov -1 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-03 23:59 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel On Sat, Sep 3, 2011 at 7:35 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> "if(sbi->s_backup_vhdr)" as you suggested didn't help. >> But I made >> another change. I made fs/hfsplus/super.c to look like this >> near the >> line 529: >> >> out_free_vhdr: >> printk(KERN_ERR "hfs: sbi->s_vhdr = >> %p, sbi->s_backup_vhdr = %p\n", >> sbi->s_vhdr, sbi->s_backup_vhdr); >> kfree(sbi->s_vhdr); >> kfree(sbi->s_backup_vhdr); >> >> And here's what I see after connecting an iPod: >> >> [ 92.549197] hfs: filesystem size too >> large blksz_shift=14, >> total_blocks=486494 >> [ 92.635714] hfs: sbi->s_vhdr = >> ffff88013703a690, sbi->s_backup_vhdr >> = ffff88013703e268 >> [ 92.730543] >> ============================================================================= >> [ 92.828425] BUG kmalloc-4096: Invalid >> object pointer 0xffff88013703a690 >> ... >> [ 93.213890] >> ============================================================================= >> [ 93.311834] BUG kmalloc-4096: Invalid >> object pointer 0xffff88013703e268 >> ... >> [ 93.868618] hfs: filesystem size too >> large blksz_shift=14, >> total_blocks=486494 >> [ 93.955327] hfs: sbi->s_vhdr = >> ffff8801343c37d8, sbi->s_backup_vhdr >> = ffff8801343c5120 >> [ 94.050133] >> ============================================================================= >> [ 94.148026] BUG kmalloc-4096: Invalid >> object pointer 0xffff8801343c37d8 >> ... >> [ 94.533895] >> ============================================================================= >> [ 94.631746] BUG kmalloc-4096: Invalid >> object pointer 0xffff8801343c5120 >> >> >> So these 2 pointers are exactly what causing the trouble. > > This is interesting... so it would appear that hfsplus_read_wrapper() isn't working correctly, but enough of correct information to pass checks. I just re-read your e-mail and your device has a logical block size of 4096 bytes, whereas most of the hfsplus code uses a block size of 512... you will need to look into hfsplus_submit_bio(), which is in the same file wrapper.c. I've looked into the code myself a little and here's what I see. hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice to fill sbi->s_vhdr and sbi->s_backup_vhdr. And according to parameters they are filled with pointers into sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf respectively. It's done with the following code at fs/hfsplus/wrapper.c:79: if (!(rw & WRITE) && data) *data = (u8 *)buf + offset; So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf and s_backup_vhdr_buf should be freed instead. And indeed changing in hfsplus_fill_super() kfree(sbi->s_vhdr); kfree(sbi->s_backup_vhdr); to kfree(sbi->s_vhdr_buf); kfree(sbi->s_backup_vhdr_buf); fixes BUG reports from SLUB. Now, the problem with "too large" error is trickier. According to this message >> [ 92.549197] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 HFS thinks that my iPod has block size of 16 KiB. But generic_check_addressable() decides that everything with blocks larger than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be addressable and thus filesystem cannot be mounted. I guess it wasn't supposed to be that way. Is hfsplus_read_wrapper() wrong in determining block size or all iPods where this was tested actually had block size 4 KiB or less? > It is going to be difficult to do anything without the actual device and 8GB is too large to be send around. Assuming it is mostly music/media and there isn't too much stuff which is too confident/private, can I ask you to send me say, the first few MB of the disk? I'll send it in a separate email bypassing lists. Pavel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-03 23:59 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-03 23:59 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel On Sat, Sep 3, 2011 at 7:35 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> "if(sbi->s_backup_vhdr)" as you suggested didn't help. >> But I made >> another change. I made fs/hfsplus/super.c to look like this >> near the >> line 529: >> >> out_free_vhdr: >> printk(KERN_ERR "hfs: sbi->s_vhdr = >> %p, sbi->s_backup_vhdr = %p\n", >> sbi->s_vhdr, sbi->s_backup_vhdr); >> kfree(sbi->s_vhdr); >> kfree(sbi->s_backup_vhdr); >> >> And here's what I see after connecting an iPod: >> >> [ 92.549197] hfs: filesystem size too >> large blksz_shift=14, >> total_blocks=486494 >> [ 92.635714] hfs: sbi->s_vhdr = >> ffff88013703a690, sbi->s_backup_vhdr >> = ffff88013703e268 >> [ 92.730543] >> ============================================================================= >> [ 92.828425] BUG kmalloc-4096: Invalid >> object pointer 0xffff88013703a690 >> ... >> [ 93.213890] >> ============================================================================= >> [ 93.311834] BUG kmalloc-4096: Invalid >> object pointer 0xffff88013703e268 >> ... >> [ 93.868618] hfs: filesystem size too >> large blksz_shift=14, >> total_blocks=486494 >> [ 93.955327] hfs: sbi->s_vhdr = >> ffff8801343c37d8, sbi->s_backup_vhdr >> = ffff8801343c5120 >> [ 94.050133] >> ============================================================================= >> [ 94.148026] BUG kmalloc-4096: Invalid >> object pointer 0xffff8801343c37d8 >> ... >> [ 94.533895] >> ============================================================================= >> [ 94.631746] BUG kmalloc-4096: Invalid >> object pointer 0xffff8801343c5120 >> >> >> So these 2 pointers are exactly what causing the trouble. > > This is interesting... so it would appear that hfsplus_read_wrapper() isn't working correctly, but enough of correct information to pass checks. I just re-read your e-mail and your device has a logical block size of 4096 bytes, whereas most of the hfsplus code uses a block size of 512... you will need to look into hfsplus_submit_bio(), which is in the same file wrapper.c. I've looked into the code myself a little and here's what I see. hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice to fill sbi->s_vhdr and sbi->s_backup_vhdr. And according to parameters they are filled with pointers into sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf respectively. It's done with the following code at fs/hfsplus/wrapper.c:79: if (!(rw & WRITE) && data) *data = (u8 *)buf + offset; So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf and s_backup_vhdr_buf should be freed instead. And indeed changing in hfsplus_fill_super() kfree(sbi->s_vhdr); kfree(sbi->s_backup_vhdr); to kfree(sbi->s_vhdr_buf); kfree(sbi->s_backup_vhdr_buf); fixes BUG reports from SLUB. Now, the problem with "too large" error is trickier. According to this message >> [ 92.549197] hfs: filesystem size too large blksz_shift=14, total_blocks=486494 HFS thinks that my iPod has block size of 16 KiB. But generic_check_addressable() decides that everything with blocks larger than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be addressable and thus filesystem cannot be mounted. I guess it wasn't supposed to be that way. Is hfsplus_read_wrapper() wrong in determining block size or all iPods where this was tested actually had block size 4 KiB or less? > It is going to be difficult to do anything without the actual device and 8GB is too large to be send around. Assuming it is mostly music/media and there isn't too much stuff which is too confident/private, can I ask you to send me say, the first few MB of the disk? I'll send it in a separate email bypassing lists. Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-03 23:59 ` Pavel Ivanov (?) @ 2011-09-04 0:37 ` Hin-Tak Leung 2011-09-06 4:35 ` Pavel Ivanov -1 siblings, 1 reply; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-04 0:37 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel --- On Sun, 4/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > On Sat, Sep 3, 2011 at 7:35 PM, > >> So these 2 pointers are exactly what causing the > trouble. > > > > This is interesting... so it would appear that > hfsplus_read_wrapper() isn't working correctly, but enough > of correct information to pass checks. I just re-read your > e-mail and your device has a logical block size of 4096 > bytes, whereas most of the hfsplus code uses a block size of > 512... you will need to look into hfsplus_submit_bio(), > which is in the same file wrapper.c. > > I've looked into the code myself a little and here's what I > see. > hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice > to fill > sbi->s_vhdr and sbi->s_backup_vhdr. And according to > parameters they > are filled with pointers into sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf respectively. It's done with the > following code > at fs/hfsplus/wrapper.c:79: > > if (!(rw & WRITE) && data) > *data = (u8 *)buf + > offset; > > So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf > and > s_backup_vhdr_buf should be freed instead. And indeed > changing in > hfsplus_fill_super() > > kfree(sbi->s_vhdr); > kfree(sbi->s_backup_vhdr); > > to > > kfree(sbi->s_vhdr_buf); > kfree(sbi->s_backup_vhdr_buf); > > fixes BUG reports from SLUB. The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer. > Now, the problem with "too large" error is trickier. > According to this message > > >> [ 92.549197] hfs: filesystem size too large > blksz_shift=14, total_blocks=486494 > > HFS thinks that my iPod has block size of 16 KiB. But > generic_check_addressable() decides that everything with > blocks larger > than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be > addressable > and thus filesystem cannot be mounted. I guess it wasn't > supposed to > be that way. Is hfsplus_read_wrapper() wrong in determining > block size > or all iPods where this was tested actually had block size > 4 KiB or > less? Your logical sector size is 4k according to dmesg and hfs block size is 512 so that 16KiB is a bit dodgy. > > It is going to be difficult to do anything without the > actual device and 8GB is too large to be send around. > Assuming it is mostly music/media and there isn't too much > stuff which is too confident/private, can I ask you to send > me say, the first few MB of the disk? > > I'll send it in a separate email bypassing lists. Thanks - I got them now. It will take a while to find my way around though... ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-04 0:37 ` Hin-Tak Leung @ 2011-09-06 4:35 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-06 4:35 UTC (permalink / raw) To: Hin-Tak Leung Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig On Sat, Sep 3, 2011 at 8:37 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> I've looked into the code myself a little and here's what I >> see. >> hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice >> to fill >> sbi->s_vhdr and sbi->s_backup_vhdr. And according to >> parameters they >> are filled with pointers into sbi->s_vhdr_buf and >> sbi->s_backup_vhdr_buf respectively. It's done with the >> following code >> at fs/hfsplus/wrapper.c:79: >> >> if (!(rw & WRITE) && data) >> *data = (u8 *)buf + >> offset; >> >> So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf >> and >> s_backup_vhdr_buf should be freed instead. And indeed >> changing in >> hfsplus_fill_super() >> >> kfree(sbi->s_vhdr); >> kfree(sbi->s_backup_vhdr); >> >> to >> >> kfree(sbi->s_vhdr_buf); >> kfree(sbi->s_backup_vhdr_buf); >> >> fixes BUG reports from SLUB. > > The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer. Well, look at the commit 6596528e. It clearly shows that result of kmalloc() is no longer assigned to sbi->s_vhdr and sbi->s_backup_vhdr, but is assigned to sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf. Also this commit clearly changes hfsplus_put_super() so that it doesn't free sbi->s_vhdr and sbi->s_backup_vhdr, but frees sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf instead. I guess Seth just missed hfsplus_fill_super() in there as it's pretty unusual exit path. >> Now, the problem with "too large" error is trickier. >> According to this message >> >> >> [ 92.549197] hfs: filesystem size too large >> blksz_shift=14, total_blocks=486494 >> >> HFS thinks that my iPod has block size of 16 KiB. But >> generic_check_addressable() decides that everything with >> blocks larger >> than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be >> addressable >> and thus filesystem cannot be mounted. I guess it wasn't >> supposed to >> be that way. Is hfsplus_read_wrapper() wrong in determining >> block size >> or all iPods where this was tested actually had block size >> 4 KiB or >> less? > > Your logical sector size is 4k according to dmesg and hfs block size is 512 so that 16KiB is a bit dodgy. I'm not sure where that "logical sector size" of 4k comes from but according to the sources 16K is taken directly from iPod via vhdr in hfsplus_read_wrapper(). And apparently all hfsplus code is designed to work with blocks larger than PAGE_SIZE. So it's just generic_check_addressable() that stands in the way. Maybe commit c6d5f5fa wasn't quite well thought through or tested by Christoph? Anyway the following patch worked for me and I've got my iPod mounted and navigateable (although only in read-only mode because it has journaled filesystem). diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..5458be4 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) struct qstr str; struct nls_table *nls = NULL; int err; + unsigned check_blksz_bits; + u64 check_num_blocks; err = -EINVAL; sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); + check_blksz_bits = sbi->alloc_blksz_shift; + check_num_blocks = sbi->total_blocks; + if (sbi->fs_shift != 0) { + check_num_blocks <<= sbi->fs_shift; + check_blksz_bits -= sbi->fs_shift; + } + err = generic_check_addressable(check_blksz_bits, check_num_blocks); if (err) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; I can format and submit both patches (plus a small cleanup that I felt is needed to be changed along the way). Tell me what you think. Pavel ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-06 4:35 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-06 4:35 UTC (permalink / raw) To: Hin-Tak Leung Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig On Sat, Sep 3, 2011 at 8:37 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> I've looked into the code myself a little and here's what I >> see. >> hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice >> to fill >> sbi->s_vhdr and sbi->s_backup_vhdr. And according to >> parameters they >> are filled with pointers into sbi->s_vhdr_buf and >> sbi->s_backup_vhdr_buf respectively. It's done with the >> following code >> at fs/hfsplus/wrapper.c:79: >> >> if (!(rw & WRITE) && data) >> *data = (u8 *)buf + >> offset; >> >> So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf >> and >> s_backup_vhdr_buf should be freed instead. And indeed >> changing in >> hfsplus_fill_super() >> >> kfree(sbi->s_vhdr); >> kfree(sbi->s_backup_vhdr); >> >> to >> >> kfree(sbi->s_vhdr_buf); >> kfree(sbi->s_backup_vhdr_buf); >> >> fixes BUG reports from SLUB. > > The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer. Well, look at the commit 6596528e. It clearly shows that result of kmalloc() is no longer assigned to sbi->s_vhdr and sbi->s_backup_vhdr, but is assigned to sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf. Also this commit clearly changes hfsplus_put_super() so that it doesn't free sbi->s_vhdr and sbi->s_backup_vhdr, but frees sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf instead. I guess Seth just missed hfsplus_fill_super() in there as it's pretty unusual exit path. >> Now, the problem with "too large" error is trickier. >> According to this message >> >> >> [ 92.549197] hfs: filesystem size too large >> blksz_shift=14, total_blocks=486494 >> >> HFS thinks that my iPod has block size of 16 KiB. But >> generic_check_addressable() decides that everything with >> blocks larger >> than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be >> addressable >> and thus filesystem cannot be mounted. I guess it wasn't >> supposed to >> be that way. Is hfsplus_read_wrapper() wrong in determining >> block size >> or all iPods where this was tested actually had block size >> 4 KiB or >> less? > > Your logical sector size is 4k according to dmesg and hfs block size is 512 so that 16KiB is a bit dodgy. I'm not sure where that "logical sector size" of 4k comes from but according to the sources 16K is taken directly from iPod via vhdr in hfsplus_read_wrapper(). And apparently all hfsplus code is designed to work with blocks larger than PAGE_SIZE. So it's just generic_check_addressable() that stands in the way. Maybe commit c6d5f5fa wasn't quite well thought through or tested by Christoph? Anyway the following patch worked for me and I've got my iPod mounted and navigateable (although only in read-only mode because it has journaled filesystem). diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..5458be4 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) struct qstr str; struct nls_table *nls = NULL; int err; + unsigned check_blksz_bits; + u64 check_num_blocks; err = -EINVAL; sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); + check_blksz_bits = sbi->alloc_blksz_shift; + check_num_blocks = sbi->total_blocks; + if (sbi->fs_shift != 0) { + check_num_blocks <<= sbi->fs_shift; + check_blksz_bits -= sbi->fs_shift; + } + err = generic_check_addressable(check_blksz_bits, check_num_blocks); if (err) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; I can format and submit both patches (plus a small cleanup that I felt is needed to be changed along the way). Tell me what you think. Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-06 4:35 ` Pavel Ivanov @ 2011-09-06 5:12 ` Hin-Tak Leung -1 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-06 5:12 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig --- On Tue, 6/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > On Sat, Sep 3, 2011 at 8:37 PM, > Hin-Tak Leung <hintak_leung@yahoo.co.uk> > wrote: > >> I've looked into the code myself a little and > here's what I > >> see. > >> hfsplus_read_wrapper() calls to > hfsplus_submit_bio() twice > >> to fill > >> sbi->s_vhdr and sbi->s_backup_vhdr. And > according to > >> parameters they > >> are filled with pointers into sbi->s_vhdr_buf > and > >> sbi->s_backup_vhdr_buf respectively. It's done > with the > >> following code > >> at fs/hfsplus/wrapper.c:79: > >> > >> if (!(rw & WRITE) && data) > >> *data = (u8 *)buf + > >> offset; > >> > >> So s_vhdr and s_backup_vhdr shouldn't be freed, > s_vhdr_buf > >> and > >> s_backup_vhdr_buf should be freed instead. And > indeed > >> changing in > >> hfsplus_fill_super() > >> > >> kfree(sbi->s_vhdr); > >> kfree(sbi->s_backup_vhdr); > >> > >> to > >> > >> kfree(sbi->s_vhdr_buf); > >> kfree(sbi->s_backup_vhdr_buf); > >> > >> fixes BUG reports from SLUB. > > > > The code around there is a bit too dense, and both of > the *_buf are recent introductions (and temp values, I > think) as is hfsplus_submit_bio() itself, around the > 2.6.39/3.0 time frame. I think the intention is to fill > s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as > temp buffer. > > Well, look at the commit 6596528e. It clearly shows that > result of > kmalloc() is no longer assigned to sbi->s_vhdr and > sbi->s_backup_vhdr, > but is assigned to sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf. Also > this commit clearly changes hfsplus_put_super() so that it > doesn't > free sbi->s_vhdr and sbi->s_backup_vhdr, but frees > sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf instead. I guess Seth just > missed > hfsplus_fill_super() in there as it's pretty unusual exit > path. Indeed. But the differing role of the *vhdr and *buf wasn't clear. > >> Now, the problem with "too large" error is > trickier. > >> According to this message > >> > >> >> [ 92.549197] hfs: filesystem size > too large > >> blksz_shift=14, total_blocks=486494 > >> > >> HFS thinks that my iPod has block size of 16 KiB. > But > >> generic_check_addressable() decides that > everything with > >> blocks larger > >> than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) > cannot be > >> addressable > >> and thus filesystem cannot be mounted. I guess it > wasn't > >> supposed to > >> be that way. Is hfsplus_read_wrapper() wrong in > determining > >> block size > >> or all iPods where this was tested actually had > block size > >> 4 KiB or > >> less? > > > > Your logical sector size is 4k according to dmesg and > hfs block size is 512 so that 16KiB is a bit dodgy. > > I'm not sure where that "logical sector size" of 4k comes > from but > according to the sources 16K is taken directly from iPod > via vhdr in > hfsplus_read_wrapper(). And apparently all hfsplus code is > designed to > work with blocks larger than PAGE_SIZE. So it's just > generic_check_addressable() that stands in the way. Maybe > commit > c6d5f5fa wasn't quite well thought through or tested by > Christoph? Yes, the 16k seem correct. The dmesg message is misleading. > Anyway the following patch worked for me and I've got my > iPod mounted > and navigateable (although only in read-only mode because > it has > journaled filesystem). I worked on the netgear journalling patches a bit: http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/patches/ But please *back up your data*, as well as reading my notes before trying them out: http://www.spinics.net/lists/linux-fsdevel/msg47684.html http://www.spinics.net/lists/linux-fsdevel/msg47734.html > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..5458be4 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > struct qstr str; > struct nls_table *nls = NULL; > int err; > + unsigned check_blksz_bits; > + u64 check_num_blocks; > > err = -EINVAL; > sbi = kzalloc(sizeof(*sbi), > GFP_KERNEL); > @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > if (!sbi->rsrc_clump_blocks) > > sbi->rsrc_clump_blocks = 1; > > - err = > generic_check_addressable(sbi->alloc_blksz_shift, > - > > sbi->total_blocks); > + check_blksz_bits = > sbi->alloc_blksz_shift; > + check_num_blocks = > sbi->total_blocks; > + if (sbi->fs_shift != 0) { > + check_num_blocks > <<= sbi->fs_shift; > + check_blksz_bits -= > sbi->fs_shift; > + } > + err = > generic_check_addressable(check_blksz_bits, > check_num_blocks); > if (err) { > printk(KERN_ERR "hfs: > filesystem size too large.\n"); > goto out_free_vhdr; > > > I can format and submit both patches (plus a small cleanup > that I felt > is needed to be changed along the way). Tell me what you > think. This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-06 5:12 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-06 5:12 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig --- On Tue, 6/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > On Sat, Sep 3, 2011 at 8:37 PM, > Hin-Tak Leung <hintak_leung@yahoo.co.uk> > wrote: > >> I've looked into the code myself a little and > here's what I > >> see. > >> hfsplus_read_wrapper() calls to > hfsplus_submit_bio() twice > >> to fill > >> sbi->s_vhdr and sbi->s_backup_vhdr. And > according to > >> parameters they > >> are filled with pointers into sbi->s_vhdr_buf > and > >> sbi->s_backup_vhdr_buf respectively. It's done > with the > >> following code > >> at fs/hfsplus/wrapper.c:79: > >> > >> if (!(rw & WRITE) && data) > >> *data = (u8 *)buf + > >> offset; > >> > >> So s_vhdr and s_backup_vhdr shouldn't be freed, > s_vhdr_buf > >> and > >> s_backup_vhdr_buf should be freed instead. And > indeed > >> changing in > >> hfsplus_fill_super() > >> > >> kfree(sbi->s_vhdr); > >> kfree(sbi->s_backup_vhdr); > >> > >> to > >> > >> kfree(sbi->s_vhdr_buf); > >> kfree(sbi->s_backup_vhdr_buf); > >> > >> fixes BUG reports from SLUB. > > > > The code around there is a bit too dense, and both of > the *_buf are recent introductions (and temp values, I > think) as is hfsplus_submit_bio() itself, around the > 2.6.39/3.0 time frame. I think the intention is to fill > s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as > temp buffer. > > Well, look at the commit 6596528e. It clearly shows that > result of > kmalloc() is no longer assigned to sbi->s_vhdr and > sbi->s_backup_vhdr, > but is assigned to sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf. Also > this commit clearly changes hfsplus_put_super() so that it > doesn't > free sbi->s_vhdr and sbi->s_backup_vhdr, but frees > sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf instead. I guess Seth just > missed > hfsplus_fill_super() in there as it's pretty unusual exit > path. Indeed. But the differing role of the *vhdr and *buf wasn't clear. > >> Now, the problem with "too large" error is > trickier. > >> According to this message > >> > >> >> [ 92.549197] hfs: filesystem size > too large > >> blksz_shift=14, total_blocks=486494 > >> > >> HFS thinks that my iPod has block size of 16 KiB. > But > >> generic_check_addressable() decides that > everything with > >> blocks larger > >> than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) > cannot be > >> addressable > >> and thus filesystem cannot be mounted. I guess it > wasn't > >> supposed to > >> be that way. Is hfsplus_read_wrapper() wrong in > determining > >> block size > >> or all iPods where this was tested actually had > block size > >> 4 KiB or > >> less? > > > > Your logical sector size is 4k according to dmesg and > hfs block size is 512 so that 16KiB is a bit dodgy. > > I'm not sure where that "logical sector size" of 4k comes > from but > according to the sources 16K is taken directly from iPod > via vhdr in > hfsplus_read_wrapper(). And apparently all hfsplus code is > designed to > work with blocks larger than PAGE_SIZE. So it's just > generic_check_addressable() that stands in the way. Maybe > commit > c6d5f5fa wasn't quite well thought through or tested by > Christoph? Yes, the 16k seem correct. The dmesg message is misleading. > Anyway the following patch worked for me and I've got my > iPod mounted > and navigateable (although only in read-only mode because > it has > journaled filesystem). I worked on the netgear journalling patches a bit: http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/patches/ But please *back up your data*, as well as reading my notes before trying them out: http://www.spinics.net/lists/linux-fsdevel/msg47684.html http://www.spinics.net/lists/linux-fsdevel/msg47734.html > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..5458be4 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > struct qstr str; > struct nls_table *nls = NULL; > int err; > + unsigned check_blksz_bits; > + u64 check_num_blocks; > > err = -EINVAL; > sbi = kzalloc(sizeof(*sbi), > GFP_KERNEL); > @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > if (!sbi->rsrc_clump_blocks) > > sbi->rsrc_clump_blocks = 1; > > - err = > generic_check_addressable(sbi->alloc_blksz_shift, > - > > sbi->total_blocks); > + check_blksz_bits = > sbi->alloc_blksz_shift; > + check_num_blocks = > sbi->total_blocks; > + if (sbi->fs_shift != 0) { > + check_num_blocks > <<= sbi->fs_shift; > + check_blksz_bits -= > sbi->fs_shift; > + } > + err = > generic_check_addressable(check_blksz_bits, > check_num_blocks); > if (err) { > printk(KERN_ERR "hfs: > filesystem size too large.\n"); > goto out_free_vhdr; > > > I can format and submit both patches (plus a small cleanup > that I felt > is needed to be changed along the way). Tell me what you > think. This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-06 5:12 ` Hin-Tak Leung @ 2011-09-06 15:09 ` Pavel Ivanov -1 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-06 15:09 UTC (permalink / raw) To: Hin-Tak Leung Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig On Tue, Sep 6, 2011 at 1:12 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> Anyway the following patch worked for me and I've got my >> iPod mounted >> and navigateable (although only in read-only mode because >> it has >> journaled filesystem). > > I worked on the netgear journalling patches a bit: > http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/patches/ > But please *back up your data*, as well as reading my notes before trying them out: > http://www.spinics.net/lists/linux-fsdevel/msg47684.html > http://www.spinics.net/lists/linux-fsdevel/msg47734.html I'd be happy to try them out and to help in testing/fixing/reviewing them. >> diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c >> index c106ca2..5458be4 100644 >> --- a/fs/hfsplus/super.c >> +++ b/fs/hfsplus/super.c >> @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct >> super_block >> *sb, void *data, int silent) >> struct qstr str; >> struct nls_table *nls = NULL; >> int err; >> + unsigned check_blksz_bits; >> + u64 check_num_blocks; >> >> err = -EINVAL; >> sbi = kzalloc(sizeof(*sbi), >> GFP_KERNEL); >> @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct >> super_block >> *sb, void *data, int silent) >> if (!sbi->rsrc_clump_blocks) >> >> sbi->rsrc_clump_blocks = 1; >> >> - err = >> generic_check_addressable(sbi->alloc_blksz_shift, >> - >> >> sbi->total_blocks); >> + check_blksz_bits = >> sbi->alloc_blksz_shift; >> + check_num_blocks = >> sbi->total_blocks; >> + if (sbi->fs_shift != 0) { >> + check_num_blocks >> <<= sbi->fs_shift; >> + check_blksz_bits -= >> sbi->fs_shift; >> + } >> + err = >> generic_check_addressable(check_blksz_bits, >> check_num_blocks); >> if (err) { >> printk(KERN_ERR "hfs: >> filesystem size too large.\n"); >> goto out_free_vhdr; >> >> >> I can format and submit both patches (plus a small cleanup >> that I felt >> is needed to be changed along the way). Tell me what you >> think. > > This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. Agreed. It was more of a quick hack to prove the correctness of such change direction. I'll think how to do it better. Thank you, Pavel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-06 15:09 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-06 15:09 UTC (permalink / raw) To: Hin-Tak Leung Cc: linux-fsdevel, linux-kernel, Seth Forshee, Christoph Hellwig On Tue, Sep 6, 2011 at 1:12 AM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: >> Anyway the following patch worked for me and I've got my >> iPod mounted >> and navigateable (although only in read-only mode because >> it has >> journaled filesystem). > > I worked on the netgear journalling patches a bit: > http://htl10.users.sourceforge.net/patchsets/hfsplus_3.0_rfc/patches/ > But please *back up your data*, as well as reading my notes before trying them out: > http://www.spinics.net/lists/linux-fsdevel/msg47684.html > http://www.spinics.net/lists/linux-fsdevel/msg47734.html I'd be happy to try them out and to help in testing/fixing/reviewing them. >> diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c >> index c106ca2..5458be4 100644 >> --- a/fs/hfsplus/super.c >> +++ b/fs/hfsplus/super.c >> @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct >> super_block >> *sb, void *data, int silent) >> struct qstr str; >> struct nls_table *nls = NULL; >> int err; >> + unsigned check_blksz_bits; >> + u64 check_num_blocks; >> >> err = -EINVAL; >> sbi = kzalloc(sizeof(*sbi), >> GFP_KERNEL); >> @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct >> super_block >> *sb, void *data, int silent) >> if (!sbi->rsrc_clump_blocks) >> >> sbi->rsrc_clump_blocks = 1; >> >> - err = >> generic_check_addressable(sbi->alloc_blksz_shift, >> - >> >> sbi->total_blocks); >> + check_blksz_bits = >> sbi->alloc_blksz_shift; >> + check_num_blocks = >> sbi->total_blocks; >> + if (sbi->fs_shift != 0) { >> + check_num_blocks >> <<= sbi->fs_shift; >> + check_blksz_bits -= >> sbi->fs_shift; >> + } >> + err = >> generic_check_addressable(check_blksz_bits, >> check_num_blocks); >> if (err) { >> printk(KERN_ERR "hfs: >> filesystem size too large.\n"); >> goto out_free_vhdr; >> >> >> I can format and submit both patches (plus a small cleanup >> that I felt >> is needed to be changed along the way). Tell me what you >> think. > > This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. Agreed. It was more of a quick hack to prove the correctness of such change direction. I'll think how to do it better. Thank you, Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-06 15:09 ` Pavel Ivanov @ 2011-09-11 3:52 ` Pavel Ivanov -1 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-11 3:52 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig On Tue, Sep 6, 2011 at 11:09 AM, Pavel Ivanov <paivanof@gmail.com> wrote: >>> diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c >>> index c106ca2..5458be4 100644 >>> --- a/fs/hfsplus/super.c >>> +++ b/fs/hfsplus/super.c >>> @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct >>> super_block >>> *sb, void *data, int silent) >>> struct qstr str; >>> struct nls_table *nls = NULL; >>> int err; >>> + unsigned check_blksz_bits; >>> + u64 check_num_blocks; >>> >>> err = -EINVAL; >>> sbi = kzalloc(sizeof(*sbi), >>> GFP_KERNEL); >>> @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct >>> super_block >>> *sb, void *data, int silent) >>> if (!sbi->rsrc_clump_blocks) >>> >>> sbi->rsrc_clump_blocks = 1; >>> >>> - err = >>> generic_check_addressable(sbi->alloc_blksz_shift, >>> - >>> >>> sbi->total_blocks); >>> + check_blksz_bits = >>> sbi->alloc_blksz_shift; >>> + check_num_blocks = >>> sbi->total_blocks; >>> + if (sbi->fs_shift != 0) { >>> + check_num_blocks >>> <<= sbi->fs_shift; >>> + check_blksz_bits -= >>> sbi->fs_shift; >>> + } >>> + err = >>> generic_check_addressable(check_blksz_bits, >>> check_num_blocks); >>> if (err) { >>> printk(KERN_ERR "hfs: >>> filesystem size too large.\n"); >>> goto out_free_vhdr; >> >> This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. > > Agreed. It was more of a quick hack to prove the correctness of such > change direction. I'll think how to do it better. Hin-Tak, How about the following patch? Subject: [PATCH] hfsplus: Allow to mount filesystem with block size greater than PAGE_SIZE Commit c6d5f5fa (hfsplus: lift the 2TB size limit) added call to generic_check_addressable() but used the system's internal block size which can be larger than PAGE_SIZE and will cause generic_check_addressable() to return -EINVAL in this case. This results in impossibility to mount file systems with such block sizes. To fix it we have to use block size understandable by generic_check_addressable() and adjust number of blocks accordingly. Signed-off-by: Pavel Ivanov <paivanof@gmail.com> Cc: <stable@kernel.org> --- diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..26ac5a5 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -399,8 +399,17 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); + /* + * Check that filesystem data can be addressed by sector_t. Obvious way + * to do that is to call generic_check_addressable with alloc_blksz_shift + * and total_blocks as parameters. But alloc_blksz_shift can be greater + * than PAGE_SIZE_SHIFT and in this case it won't be accepted by + * generic_check_addressable. s_blocksize_bits will always be accepted + * and difference between it and alloc_blksz_shift will be always in + * fs_shift. + */ + err = generic_check_addressable(sb->s_blocksize_bits, + (u64)sbi->total_blocks << sbi->fs_shift); if (err) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; -- ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-11 3:52 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-11 3:52 UTC (permalink / raw) To: Hin-Tak Leung; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig On Tue, Sep 6, 2011 at 11:09 AM, Pavel Ivanov <paivanof@gmail.com> wrote: >>> diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c >>> index c106ca2..5458be4 100644 >>> --- a/fs/hfsplus/super.c >>> +++ b/fs/hfsplus/super.c >>> @@ -345,6 +345,8 @@ static int hfsplus_fill_super(struct >>> super_block >>> *sb, void *data, int silent) >>> struct qstr str; >>> struct nls_table *nls = NULL; >>> int err; >>> + unsigned check_blksz_bits; >>> + u64 check_num_blocks; >>> >>> err = -EINVAL; >>> sbi = kzalloc(sizeof(*sbi), >>> GFP_KERNEL); >>> @@ -399,10 +401,15 @@ static int hfsplus_fill_super(struct >>> super_block >>> *sb, void *data, int silent) >>> if (!sbi->rsrc_clump_blocks) >>> >>> sbi->rsrc_clump_blocks = 1; >>> >>> - err = >>> generic_check_addressable(sbi->alloc_blksz_shift, >>> - >>> >>> sbi->total_blocks); >>> + check_blksz_bits = >>> sbi->alloc_blksz_shift; >>> + check_num_blocks = >>> sbi->total_blocks; >>> + if (sbi->fs_shift != 0) { >>> + check_num_blocks >>> <<= sbi->fs_shift; >>> + check_blksz_bits -= >>> sbi->fs_shift; >>> + } >>> + err = >>> generic_check_addressable(check_blksz_bits, >>> check_num_blocks); >>> if (err) { >>> printk(KERN_ERR "hfs: >>> filesystem size too large.\n"); >>> goto out_free_vhdr; >> >> This is a bit ugly - what it does is massage the two values taking into account of sbi->fs_shift to pass check_addressable() . I think either check_addressable should be extended, or this be abstracted out say, to check_hfs_addressable() (with __inline__ if desired) to be cleaner. > > Agreed. It was more of a quick hack to prove the correctness of such > change direction. I'll think how to do it better. Hin-Tak, How about the following patch? Subject: [PATCH] hfsplus: Allow to mount filesystem with block size greater than PAGE_SIZE Commit c6d5f5fa (hfsplus: lift the 2TB size limit) added call to generic_check_addressable() but used the system's internal block size which can be larger than PAGE_SIZE and will cause generic_check_addressable() to return -EINVAL in this case. This results in impossibility to mount file systems with such block sizes. To fix it we have to use block size understandable by generic_check_addressable() and adjust number of blocks accordingly. Signed-off-by: Pavel Ivanov <paivanof@gmail.com> Cc: <stable@kernel.org> --- diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..26ac5a5 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -399,8 +399,17 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); + /* + * Check that filesystem data can be addressed by sector_t. Obvious way + * to do that is to call generic_check_addressable with alloc_blksz_shift + * and total_blocks as parameters. But alloc_blksz_shift can be greater + * than PAGE_SIZE_SHIFT and in this case it won't be accepted by + * generic_check_addressable. s_blocksize_bits will always be accepted + * and difference between it and alloc_blksz_shift will be always in + * fs_shift. + */ + err = generic_check_addressable(sb->s_blocksize_bits, + (u64)sbi->total_blocks << sbi->fs_shift); if (err) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; -- -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 3:52 ` Pavel Ivanov @ 2011-09-11 13:46 ` Hin-Tak Leung -1 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-11 13:46 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig --- On Sun, 11/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > How about the following patch? > > > Subject: [PATCH] hfsplus: Allow to mount filesystem with > block size > greater than PAGE_SIZE > > Commit c6d5f5fa (hfsplus: lift the 2TB size limit) added > call to > generic_check_addressable() but used the system's internal > block size > which can be larger than PAGE_SIZE and will cause > generic_check_addressable() to return -EINVAL in this case. > This > results in impossibility to mount file systems with such > block sizes. > To fix it we have to use block size understandable by > generic_check_addressable() and adjust number of blocks > accordingly. > > Signed-off-by: Pavel Ivanov <paivanof@gmail.com> > Cc: <stable@kernel.org> > --- > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..26ac5a5 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -399,8 +399,17 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > if (!sbi->rsrc_clump_blocks) > > sbi->rsrc_clump_blocks = 1; > > - err = > generic_check_addressable(sbi->alloc_blksz_shift, > - > > sbi->total_blocks); > + /* > + * Check that filesystem data > can be addressed by sector_t. Obvious way > + * to do that is to call > generic_check_addressable with alloc_blksz_shift > + * and total_blocks as > parameters. But alloc_blksz_shift can be greater > + * than PAGE_SIZE_SHIFT and > in this case it won't be accepted by > + * generic_check_addressable. > s_blocksize_bits will always be accepted > + * and difference between it > and alloc_blksz_shift will be always in > + * fs_shift. > + */ > + err = > generic_check_addressable(sb->s_blocksize_bits, > + > (u64)sbi->total_blocks << sbi->fs_shift); > if (err) { > printk(KERN_ERR > "hfs: filesystem size too large.\n"); > goto out_free_vhdr; Why is the u64 needed? If it is needed, it probably means sbi->total_blocks should have been u64 in the first place. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-11 13:46 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-11 13:46 UTC (permalink / raw) To: Pavel Ivanov; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig --- On Sun, 11/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > How about the following patch? > > > Subject: [PATCH] hfsplus: Allow to mount filesystem with > block size > greater than PAGE_SIZE > > Commit c6d5f5fa (hfsplus: lift the 2TB size limit) added > call to > generic_check_addressable() but used the system's internal > block size > which can be larger than PAGE_SIZE and will cause > generic_check_addressable() to return -EINVAL in this case. > This > results in impossibility to mount file systems with such > block sizes. > To fix it we have to use block size understandable by > generic_check_addressable() and adjust number of blocks > accordingly. > > Signed-off-by: Pavel Ivanov <paivanof@gmail.com> > Cc: <stable@kernel.org> > --- > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..26ac5a5 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -399,8 +399,17 @@ static int hfsplus_fill_super(struct > super_block > *sb, void *data, int silent) > if (!sbi->rsrc_clump_blocks) > > sbi->rsrc_clump_blocks = 1; > > - err = > generic_check_addressable(sbi->alloc_blksz_shift, > - > > sbi->total_blocks); > + /* > + * Check that filesystem data > can be addressed by sector_t. Obvious way > + * to do that is to call > generic_check_addressable with alloc_blksz_shift > + * and total_blocks as > parameters. But alloc_blksz_shift can be greater > + * than PAGE_SIZE_SHIFT and > in this case it won't be accepted by > + * generic_check_addressable. > s_blocksize_bits will always be accepted > + * and difference between it > and alloc_blksz_shift will be always in > + * fs_shift. > + */ > + err = > generic_check_addressable(sb->s_blocksize_bits, > + > (u64)sbi->total_blocks << sbi->fs_shift); > if (err) { > printk(KERN_ERR > "hfs: filesystem size too large.\n"); > goto out_free_vhdr; Why is the u64 needed? If it is needed, it probably means sbi->total_blocks should have been u64 in the first place. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 13:46 ` Hin-Tak Leung (?) @ 2011-09-11 14:14 ` Christoph Hellwig -1 siblings, 0 replies; 45+ messages in thread From: Christoph Hellwig @ 2011-09-11 14:14 UTC (permalink / raw) To: Hin-Tak Leung Cc: Pavel Ivanov, linux-fsdevel, linux-kernel, Christoph Hellwig On Sun, Sep 11, 2011 at 02:46:08PM +0100, Hin-Tak Leung wrote: > > +?????* and difference between it > > and alloc_blksz_shift will be always in > > +?????* fs_shift. > > +?????*/ > > +??? err = > > generic_check_addressable(sb->s_blocksize_bits, > > +??? ??? ??? > > (u64)sbi->total_blocks << sbi->fs_shift); > > ??? if (err) { > > ??? ??? printk(KERN_ERR > > "hfs: filesystem size too large.\n"); > > ??? ??? goto out_free_vhdr; > > Why is the u64 needed? If it is needed, it probably means sbi->total_blocks should have been u64 in the first place. No. When you shift values to the left they obviously become larger. The total_blocks count on disk 32-bit so there is no need to store it in a larger variable in the in-core superblock. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 3:52 ` Pavel Ivanov (?) (?) @ 2011-09-11 14:12 ` Christoph Hellwig -1 siblings, 0 replies; 45+ messages in thread From: Christoph Hellwig @ 2011-09-11 14:12 UTC (permalink / raw) To: Pavel Ivanov Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Sat, Sep 10, 2011 at 11:52:55PM -0400, Pavel Ivanov wrote: > > Agreed. It was more of a quick hack to prove the correctness of such > > change direction. I'll think how to do it better. > > Hin-Tak, > > How about the following patch? > > > Subject: [PATCH] hfsplus: Allow to mount filesystem with block size > greater than PAGE_SIZE > > Commit c6d5f5fa (hfsplus: lift the 2TB size limit) added call to > generic_check_addressable() but used the system's internal block size > which can be larger than PAGE_SIZE and will cause > generic_check_addressable() to return -EINVAL in this case. This > results in impossibility to mount file systems with such block sizes. > To fix it we have to use block size understandable by > generic_check_addressable() and adjust number of blocks accordingly. Given that a large part of the checks are related to the actual block size I think that we're better off just opencoding it. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 3:52 ` Pavel Ivanov ` (2 preceding siblings ...) (?) @ 2011-09-12 14:34 ` Christoph Hellwig 2011-09-12 15:19 ` Pavel Ivanov -1 siblings, 1 reply; 45+ messages in thread From: Christoph Hellwig @ 2011-09-12 14:34 UTC (permalink / raw) To: Pavel Ivanov Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig Does this patch fix your issues with large block sizes? Index: linux-2.6/fs/hfsplus/super.c =================================================================== --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 09:56:58.619988416 -0400 +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 10:07:18.006651395 -0400 @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup struct inode *root, *inode; struct qstr str; struct nls_table *nls = NULL; + u64 last_fs_block, last_fs_page; int err; err = -EINVAL; @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); - if (err) { + err = -EFBIG; + last_fs_block = sbi->total_blocks - 1; + last_fs_page = (last_fs_block >> sbi->alloc_blksz_shift) << + PAGE_CACHE_SHIFT; + + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || + (last_fs_page > (pgoff_t)(~0ULL))) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; } ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-12 14:34 ` Christoph Hellwig @ 2011-09-12 15:19 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-12 15:19 UTC (permalink / raw) To: Christoph Hellwig Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Mon, Sep 12, 2011 at 10:34 AM, Christoph Hellwig <hch@infradead.org> wrote: > Does this patch fix your issues with large block sizes? I'll be able to try it in the evening but meanwhile I have some comments below. > > > Index: linux-2.6/fs/hfsplus/super.c > =================================================================== > --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 09:56:58.619988416 -0400 > +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 10:07:18.006651395 -0400 > @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup > struct inode *root, *inode; > struct qstr str; > struct nls_table *nls = NULL; > + u64 last_fs_block, last_fs_page; > int err; > > err = -EINVAL; > @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup > if (!sbi->rsrc_clump_blocks) > sbi->rsrc_clump_blocks = 1; > > - err = generic_check_addressable(sbi->alloc_blksz_shift, > - sbi->total_blocks); > - if (err) { > + err = -EFBIG; > + last_fs_block = sbi->total_blocks - 1; > + last_fs_page = (last_fs_block >> sbi->alloc_blksz_shift) << > + PAGE_CACHE_SHIFT; Did you mix left and right shifts here? Expression doesn't make sense to me. Also I have a little concern about consistency in using PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() limits visible block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although now they are equal comment in linux/pagemap.h clearly says that PAGE_CACHE_SIZE can be bigger than PAGE_SIZE. Is it something that should be fixed in hfsplus_read_wrapper() ? > + > + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || Maybe this 9 should be extracted from here and generic_check_addressable() into some macro? > + (last_fs_page > (pgoff_t)(~0ULL))) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > } > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-12 15:19 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-12 15:19 UTC (permalink / raw) To: Christoph Hellwig Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Mon, Sep 12, 2011 at 10:34 AM, Christoph Hellwig <hch@infradead.org> wrote: > Does this patch fix your issues with large block sizes? I'll be able to try it in the evening but meanwhile I have some comments below. > > > Index: linux-2.6/fs/hfsplus/super.c > =================================================================== > --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 09:56:58.619988416 -0400 > +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 10:07:18.006651395 -0400 > @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup > struct inode *root, *inode; > struct qstr str; > struct nls_table *nls = NULL; > + u64 last_fs_block, last_fs_page; > int err; > > err = -EINVAL; > @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup > if (!sbi->rsrc_clump_blocks) > sbi->rsrc_clump_blocks = 1; > > - err = generic_check_addressable(sbi->alloc_blksz_shift, > - sbi->total_blocks); > - if (err) { > + err = -EFBIG; > + last_fs_block = sbi->total_blocks - 1; > + last_fs_page = (last_fs_block >> sbi->alloc_blksz_shift) << > + PAGE_CACHE_SHIFT; Did you mix left and right shifts here? Expression doesn't make sense to me. Also I have a little concern about consistency in using PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() limits visible block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although now they are equal comment in linux/pagemap.h clearly says that PAGE_CACHE_SIZE can be bigger than PAGE_SIZE. Is it something that should be fixed in hfsplus_read_wrapper() ? > + > + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || Maybe this 9 should be extracted from here and generic_check_addressable() into some macro? > + (last_fs_page > (pgoff_t)(~0ULL))) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-12 15:19 ` Pavel Ivanov (?) @ 2011-09-12 15:31 ` Christoph Hellwig 2011-09-13 2:20 ` Pavel Ivanov -1 siblings, 1 reply; 45+ messages in thread From: Christoph Hellwig @ 2011-09-12 15:31 UTC (permalink / raw) To: Pavel Ivanov Cc: Christoph Hellwig, Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig Yes, the shifts were the wrong way around. I'll leave the 9 in for now, we use it in so many places and if we're going to clean it up I'd do it in ne go. Index: linux-2.6/fs/hfsplus/super.c =================================================================== --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 11:20:33.866598100 -0400 +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 11:20:52.538098052 -0400 @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup struct inode *root, *inode; struct qstr str; struct nls_table *nls = NULL; + u64 last_fs_block, last_fs_page; int err; err = -EINVAL; @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup if (!sbi->rsrc_clump_blocks) sbi->rsrc_clump_blocks = 1; - err = generic_check_addressable(sbi->alloc_blksz_shift, - sbi->total_blocks); - if (err) { + err = -EFBIG; + last_fs_block = sbi->total_blocks - 1; + last_fs_page = (last_fs_block << sbi->alloc_blksz_shift) >> + PAGE_CACHE_SHIFT; + + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || + (last_fs_page > (pgoff_t)(~0ULL))) { printk(KERN_ERR "hfs: filesystem size too large.\n"); goto out_free_vhdr; } ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-12 15:31 ` Christoph Hellwig @ 2011-09-13 2:20 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-13 2:20 UTC (permalink / raw) To: Christoph Hellwig Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Mon, Sep 12, 2011 at 11:31 AM, Christoph Hellwig <hch@infradead.org> wrote: > Yes, the shifts were the wrong way around. I'll leave the 9 in for now, > we use it in so many places and if we're going to clean it up I'd do it > in ne go. > > Index: linux-2.6/fs/hfsplus/super.c > =================================================================== > --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 11:20:33.866598100 -0400 > +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 11:20:52.538098052 -0400 > @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup > struct inode *root, *inode; > struct qstr str; > struct nls_table *nls = NULL; > + u64 last_fs_block, last_fs_page; > int err; > > err = -EINVAL; > @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup > if (!sbi->rsrc_clump_blocks) > sbi->rsrc_clump_blocks = 1; > > - err = generic_check_addressable(sbi->alloc_blksz_shift, > - sbi->total_blocks); > - if (err) { > + err = -EFBIG; > + last_fs_block = sbi->total_blocks - 1; > + last_fs_page = (last_fs_block << sbi->alloc_blksz_shift) >> > + PAGE_CACHE_SHIFT; > + > + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || > + (last_fs_page > (pgoff_t)(~0ULL))) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > } > Christoph, This patch works for me. And could you comment on my PAGE_SIZE question? >> Also I have a little concern about consistency in using >> PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() limits visible >> block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although now they >> are equal comment in linux/pagemap.h clearly says that PAGE_CACHE_SIZE >> can be bigger than PAGE_SIZE. Is it something that should be fixed in >> hfsplus_read_wrapper() ? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-13 2:20 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-13 2:20 UTC (permalink / raw) To: Christoph Hellwig Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Mon, Sep 12, 2011 at 11:31 AM, Christoph Hellwig <hch@infradead.org> wrote: > Yes, the shifts were the wrong way around. I'll leave the 9 in for now, > we use it in so many places and if we're going to clean it up I'd do it > in ne go. > > Index: linux-2.6/fs/hfsplus/super.c > =================================================================== > --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 11:20:33.866598100 -0400 > +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 11:20:52.538098052 -0400 > @@ -344,6 +344,7 @@ static int hfsplus_fill_super(struct sup > struct inode *root, *inode; > struct qstr str; > struct nls_table *nls = NULL; > + u64 last_fs_block, last_fs_page; > int err; > > err = -EINVAL; > @@ -399,9 +400,13 @@ static int hfsplus_fill_super(struct sup > if (!sbi->rsrc_clump_blocks) > sbi->rsrc_clump_blocks = 1; > > - err = generic_check_addressable(sbi->alloc_blksz_shift, > - sbi->total_blocks); > - if (err) { > + err = -EFBIG; > + last_fs_block = sbi->total_blocks - 1; > + last_fs_page = (last_fs_block << sbi->alloc_blksz_shift) >> > + PAGE_CACHE_SHIFT; > + > + if ((last_fs_block > (sector_t)(~0ULL) >> (sbi->alloc_blksz_shift - 9)) || > + (last_fs_page > (pgoff_t)(~0ULL))) { > printk(KERN_ERR "hfs: filesystem size too large.\n"); > goto out_free_vhdr; > } > Christoph, This patch works for me. And could you comment on my PAGE_SIZE question? >> Also I have a little concern about consistency in using >> PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() limits visible >> block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although now they >> are equal comment in linux/pagemap.h clearly says that PAGE_CACHE_SIZE >> can be bigger than PAGE_SIZE. Is it something that should be fixed in >> hfsplus_read_wrapper() ? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-13 2:20 ` Pavel Ivanov (?) @ 2011-09-14 17:42 ` Christoph Hellwig 2011-09-15 14:35 ` Christoph Hellwig -1 siblings, 1 reply; 45+ messages in thread From: Christoph Hellwig @ 2011-09-14 17:42 UTC (permalink / raw) To: Pavel Ivanov Cc: Christoph Hellwig, Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Mon, Sep 12, 2011 at 10:20:01PM -0400, Pavel Ivanov wrote: > This patch works for me. > > And could you comment on my PAGE_SIZE question? > > >> Also I have a little concern about consistency in using > >> PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() limits visible > >> block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although now they > >> are equal comment in linux/pagemap.h clearly says that PAGE_CACHE_SIZE > >> can be bigger than PAGE_SIZE. Is it something that should be fixed in > >> hfsplus_read_wrapper() ? The two are and always have been the same. There were plans to allow for a larger PAGE_CACHE_SIZE long time ago, but it never happened. I'll switch everything to PAGE_SIZE in the patch for consistency. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-14 17:42 ` Christoph Hellwig @ 2011-09-15 14:35 ` Christoph Hellwig 0 siblings, 0 replies; 45+ messages in thread From: Christoph Hellwig @ 2011-09-15 14:35 UTC (permalink / raw) To: Pavel Ivanov Cc: Christoph Hellwig, Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Wed, Sep 14, 2011 at 01:42:50PM -0400, Christoph Hellwig wrote: > I'll switch everything to PAGE_SIZE in the patch for consistency. I'll take that back. hfsplus is mostly using PAGE_CACHE_SIZE and friends, so I'll fix the few uses of plain PAGE_SIZE instead. But that's 3.2 material. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-12 15:19 ` Pavel Ivanov (?) (?) @ 2011-09-12 15:57 ` Hin-Tak Leung -1 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-12 15:57 UTC (permalink / raw) To: Christoph Hellwig, Pavel Ivanov Cc: linux-fsdevel, linux-kernel, Christoph Hellwig --- On Mon, 12/9/11, Pavel Ivanov <paivanof@gmail.com> wrote: > On Mon, Sep 12, 2011 at 10:34 AM, > Christoph Hellwig <hch@infradead.org> > wrote: > > Does this patch fix your issues with large block > sizes? > > I'll be able to try it in the evening but meanwhile I have > some comments below. > > > > > > > Index: linux-2.6/fs/hfsplus/super.c > > > =================================================================== > > --- linux-2.6.orig/fs/hfsplus/super.c 2011-09-12 > 09:56:58.619988416 -0400 > > +++ linux-2.6/fs/hfsplus/super.c 2011-09-12 > 10:07:18.006651395 -0400 > > @@ -344,6 +344,7 @@ static int > hfsplus_fill_super(struct sup > > struct inode *root, *inode; > > struct qstr str; > > struct nls_table *nls = NULL; > > + u64 last_fs_block, last_fs_page; > > int err; > > > > err = -EINVAL; > > @@ -399,9 +400,13 @@ static int > hfsplus_fill_super(struct sup > > if (!sbi->rsrc_clump_blocks) > > sbi->rsrc_clump_blocks = 1; > > > > - err = > generic_check_addressable(sbi->alloc_blksz_shift, > > - > sbi->total_blocks); > > - if (err) { > > + err = -EFBIG; > > + last_fs_block = sbi->total_blocks - 1; > > + last_fs_page = (last_fs_block >> > sbi->alloc_blksz_shift) << > > + PAGE_CACHE_SHIFT; > > Did you mix left and right shifts here? Expression doesn't > make sense to me. > > Also I have a little concern about consistency in using > PAGE_CACHE_SHIFT and PAGE_SHIFT. hfsplus_read_wrapper() > limits visible > block size to PAGE_SIZE, not PAGE_CACHE_SIZE. And although > now they > are equal comment in linux/pagemap.h clearly says that > PAGE_CACHE_SIZE > can be bigger than PAGE_SIZE. Is it something that should > be fixed in > hfsplus_read_wrapper() ? > > > + > > + if ((last_fs_block > (sector_t)(~0ULL) > >> (sbi->alloc_blksz_shift - 9)) || > > Maybe this 9 should be extracted from here and > generic_check_addressable() into some macro? > > > + (last_fs_page > (pgoff_t)(~0ULL))) > { > > printk(KERN_ERR "hfs: > filesystem size too large.\n"); > > goto out_free_vhdr; > > } > > I 2nd that this is kind of ugly. The literal "9". How about abstracting this logic out to say, hfs_check_addressable()? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-06 4:35 ` Pavel Ivanov @ 2011-09-07 17:59 ` Seth Forshee -1 siblings, 0 replies; 45+ messages in thread From: Seth Forshee @ 2011-09-07 17:59 UTC (permalink / raw) To: Pavel Ivanov Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Tue, Sep 06, 2011 at 12:35:22AM -0400, Pavel Ivanov wrote: > On Sat, Sep 3, 2011 at 8:37 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: > >> I've looked into the code myself a little and here's what I > >> see. > >> hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice > >> to fill > >> sbi->s_vhdr and sbi->s_backup_vhdr. And according to > >> parameters they > >> are filled with pointers into sbi->s_vhdr_buf and > >> sbi->s_backup_vhdr_buf respectively. It's done with the > >> following code > >> at fs/hfsplus/wrapper.c:79: > >> > >> if (!(rw & WRITE) && data) > >> *data = (u8 *)buf + > >> offset; > >> > >> So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf > >> and > >> s_backup_vhdr_buf should be freed instead. And indeed > >> changing in > >> hfsplus_fill_super() > >> > >> kfree(sbi->s_vhdr); > >> kfree(sbi->s_backup_vhdr); > >> > >> to > >> > >> kfree(sbi->s_vhdr_buf); > >> kfree(sbi->s_backup_vhdr_buf); > >> > >> fixes BUG reports from SLUB. > > > > The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer. > > Well, look at the commit 6596528e. It clearly shows that result of > kmalloc() is no longer assigned to sbi->s_vhdr and sbi->s_backup_vhdr, > but is assigned to sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf. Also > this commit clearly changes hfsplus_put_super() so that it doesn't > free sbi->s_vhdr and sbi->s_backup_vhdr, but frees sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf instead. I guess Seth just missed > hfsplus_fill_super() in there as it's pretty unusual exit path. Yes, that was definitely just an oversight. Has anyone provided a patch yet? If not I've pasted a patch below. Seems like a fix should be applied ASAP. >From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 00:00:00 2001 From: Seth Forshee <seth.forshee@canonical.com> Date: Wed, 7 Sep 2011 10:38:35 -0700 Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in hfsplus_fill_super() error path Commit 6596528 (hfsplus: ensure bio requests are not smaller than the hardware sectors) changed the pointers used for volume header allocations but failed to change the pointer freed in the error path of hfsplus_fill_super(). This patch fixes the problem. Reported-by: Pavel Ivanov <paivanof@gmail.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Cc: <stable@kernel.org> --- fs/hfsplus/super.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..cadbb8c 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -525,8 +525,8 @@ out_close_cat_tree: out_close_ext_tree: hfs_btree_close(sbi->ext_tree); out_free_vhdr: - kfree(sbi->s_vhdr); - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_vhdr_buf); + kfree(sbi->s_backup_vhdr_buf); out_unload_nls: unload_nls(sbi->nls); unload_nls(nls); -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-07 17:59 ` Seth Forshee 0 siblings, 0 replies; 45+ messages in thread From: Seth Forshee @ 2011-09-07 17:59 UTC (permalink / raw) To: Pavel Ivanov Cc: Hin-Tak Leung, linux-fsdevel, linux-kernel, Christoph Hellwig On Tue, Sep 06, 2011 at 12:35:22AM -0400, Pavel Ivanov wrote: > On Sat, Sep 3, 2011 at 8:37 PM, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote: > >> I've looked into the code myself a little and here's what I > >> see. > >> hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice > >> to fill > >> sbi->s_vhdr and sbi->s_backup_vhdr. And according to > >> parameters they > >> are filled with pointers into sbi->s_vhdr_buf and > >> sbi->s_backup_vhdr_buf respectively. It's done with the > >> following code > >> at fs/hfsplus/wrapper.c:79: > >> > >> if (!(rw & WRITE) && data) > >> *data = (u8 *)buf + > >> offset; > >> > >> So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf > >> and > >> s_backup_vhdr_buf should be freed instead. And indeed > >> changing in > >> hfsplus_fill_super() > >> > >> kfree(sbi->s_vhdr); > >> kfree(sbi->s_backup_vhdr); > >> > >> to > >> > >> kfree(sbi->s_vhdr_buf); > >> kfree(sbi->s_backup_vhdr_buf); > >> > >> fixes BUG reports from SLUB. > > > > The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer. > > Well, look at the commit 6596528e. It clearly shows that result of > kmalloc() is no longer assigned to sbi->s_vhdr and sbi->s_backup_vhdr, > but is assigned to sbi->s_vhdr_buf and sbi->s_backup_vhdr_buf. Also > this commit clearly changes hfsplus_put_super() so that it doesn't > free sbi->s_vhdr and sbi->s_backup_vhdr, but frees sbi->s_vhdr_buf and > sbi->s_backup_vhdr_buf instead. I guess Seth just missed > hfsplus_fill_super() in there as it's pretty unusual exit path. Yes, that was definitely just an oversight. Has anyone provided a patch yet? If not I've pasted a patch below. Seems like a fix should be applied ASAP. From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 00:00:00 2001 From: Seth Forshee <seth.forshee@canonical.com> Date: Wed, 7 Sep 2011 10:38:35 -0700 Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in hfsplus_fill_super() error path Commit 6596528 (hfsplus: ensure bio requests are not smaller than the hardware sectors) changed the pointers used for volume header allocations but failed to change the pointer freed in the error path of hfsplus_fill_super(). This patch fixes the problem. Reported-by: Pavel Ivanov <paivanof@gmail.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Cc: <stable@kernel.org> --- fs/hfsplus/super.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..cadbb8c 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -525,8 +525,8 @@ out_close_cat_tree: out_close_ext_tree: hfs_btree_close(sbi->ext_tree); out_free_vhdr: - kfree(sbi->s_vhdr); - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_vhdr_buf); + kfree(sbi->s_backup_vhdr_buf); out_unload_nls: unload_nls(sbi->nls); unload_nls(nls); -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-07 17:59 ` Seth Forshee @ 2011-09-08 3:13 ` Hin-Tak Leung -1 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-08 3:13 UTC (permalink / raw) To: Pavel Ivanov, Seth Forshee; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig --- On Wed, 7/9/11, Seth Forshee <seth.forshee@canonical.com> wrote: > Yes, that was definitely just an oversight. Has anyone > provided a patch > yet? If not I've pasted a patch below. Seems like a fix > should be > applied ASAP. > > > From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 > 00:00:00 2001 > From: Seth Forshee <seth.forshee@canonical.com> > Date: Wed, 7 Sep 2011 10:38:35 -0700 > Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in > hfsplus_fill_super() error path > > Commit 6596528 (hfsplus: ensure bio requests are not > smaller than > the hardware sectors) changed the pointers used for volume > header > allocations but failed to change the pointer freed in the > error > path of hfsplus_fill_super(). This patch fixes the > problem. > > Reported-by: Pavel Ivanov <paivanof@gmail.com> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > Cc: <stable@kernel.org> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Please go ahead and submit the patch. > --- > fs/hfsplus/super.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..cadbb8c 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -525,8 +525,8 @@ out_close_cat_tree: > out_close_ext_tree: > hfs_btree_close(sbi->ext_tree); > out_free_vhdr: > - kfree(sbi->s_vhdr); > - kfree(sbi->s_backup_vhdr); > + kfree(sbi->s_vhdr_buf); > + kfree(sbi->s_backup_vhdr_buf); > out_unload_nls: > unload_nls(sbi->nls); > unload_nls(nls); > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-08 3:13 ` Hin-Tak Leung 0 siblings, 0 replies; 45+ messages in thread From: Hin-Tak Leung @ 2011-09-08 3:13 UTC (permalink / raw) To: Pavel Ivanov, Seth Forshee; +Cc: linux-fsdevel, linux-kernel, Christoph Hellwig --- On Wed, 7/9/11, Seth Forshee <seth.forshee@canonical.com> wrote: > Yes, that was definitely just an oversight. Has anyone > provided a patch > yet? If not I've pasted a patch below. Seems like a fix > should be > applied ASAP. > > > From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 > 00:00:00 2001 > From: Seth Forshee <seth.forshee@canonical.com> > Date: Wed, 7 Sep 2011 10:38:35 -0700 > Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in > hfsplus_fill_super() error path > > Commit 6596528 (hfsplus: ensure bio requests are not > smaller than > the hardware sectors) changed the pointers used for volume > header > allocations but failed to change the pointer freed in the > error > path of hfsplus_fill_super(). This patch fixes the > problem. > > Reported-by: Pavel Ivanov <paivanof@gmail.com> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > Cc: <stable@kernel.org> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Please go ahead and submit the patch. > --- > fs/hfsplus/super.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index c106ca2..cadbb8c 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -525,8 +525,8 @@ out_close_cat_tree: > out_close_ext_tree: > hfs_btree_close(sbi->ext_tree); > out_free_vhdr: > - kfree(sbi->s_vhdr); > - kfree(sbi->s_backup_vhdr); > + kfree(sbi->s_vhdr_buf); > + kfree(sbi->s_backup_vhdr_buf); > out_unload_nls: > unload_nls(sbi->nls); > unload_nls(nls); > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-08 3:13 ` Hin-Tak Leung (?) @ 2011-09-08 16:23 ` Seth Forshee 2011-09-09 12:48 ` Christoph Hellwig 2011-09-11 3:32 ` Pavel Ivanov -1 siblings, 2 replies; 45+ messages in thread From: Seth Forshee @ 2011-09-08 16:23 UTC (permalink / raw) To: Hin-Tak Leung, Christoph Hellwig Cc: Pavel Ivanov, linux-fsdevel, linux-kernel On Thu, Sep 08, 2011 at 04:13:01AM +0100, Hin-Tak Leung wrote: > --- On Wed, 7/9/11, Seth Forshee <seth.forshee@canonical.com> wrote: > > > Yes, that was definitely just an oversight. Has anyone > > provided a patch > > yet? If not I've pasted a patch below. Seems like a fix > > should be > > applied ASAP. > > > > > > From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 > > 00:00:00 2001 > > From: Seth Forshee <seth.forshee@canonical.com> > > Date: Wed, 7 Sep 2011 10:38:35 -0700 > > Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in > > hfsplus_fill_super() error path > > > > Commit 6596528 (hfsplus: ensure bio requests are not > > smaller than > > the hardware sectors) changed the pointers used for volume > > header > > allocations but failed to change the pointer freed in the > > error > > path of hfsplus_fill_super(). This patch fixes the > > problem. > > > > Reported-by: Pavel Ivanov <paivanof@gmail.com> > > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> > > Cc: <stable@kernel.org> > > Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> > > Please go ahead and submit the patch. That was my patch submission :) Christoph, does that work for you, or would you like me to send the patch in a separate email? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-08 16:23 ` Seth Forshee @ 2011-09-09 12:48 ` Christoph Hellwig 2011-09-11 3:32 ` Pavel Ivanov 1 sibling, 0 replies; 45+ messages in thread From: Christoph Hellwig @ 2011-09-09 12:48 UTC (permalink / raw) To: Hin-Tak Leung, Christoph Hellwig, Pavel Ivanov, linux-fsdevel, linux-kernel On Thu, Sep 08, 2011 at 09:23:04AM -0700, Seth Forshee wrote: > That was my patch submission :) > > Christoph, does that work for you, or would you like me to send the > patch in a separate email? The submission is fine. I'll try to find a QA setup to test it properly and will send it on to Linus afterwards. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-08 16:23 ` Seth Forshee @ 2011-09-11 3:32 ` Pavel Ivanov 2011-09-11 3:32 ` Pavel Ivanov 1 sibling, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-11 3:32 UTC (permalink / raw) To: Hin-Tak Leung, Christoph Hellwig, Pavel Ivanov, linux-fsdevel, linux-kernel, Seth Forshee On Thu, Sep 8, 2011 at 12:23 PM, Seth Forshee <seth.forshee@canonical.com> wrote: > On Thu, Sep 08, 2011 at 04:13:01AM +0100, Hin-Tak Leung wrote: >> --- On Wed, 7/9/11, Seth Forshee <seth.forshee@canonical.com> wrote: >> >> > Yes, that was definitely just an oversight. Has anyone >> > provided a patch >> > yet? If not I've pasted a patch below. Seems like a fix >> > should be >> > applied ASAP. >> > >> > >> > From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 >> > 00:00:00 2001 >> > From: Seth Forshee <seth.forshee@canonical.com> >> > Date: Wed, 7 Sep 2011 10:38:35 -0700 >> > Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in >> > hfsplus_fill_super() error path >> > >> > Commit 6596528 (hfsplus: ensure bio requests are not >> > smaller than >> > the hardware sectors) changed the pointers used for volume >> > header >> > allocations but failed to change the pointer freed in the >> > error >> > path of hfsplus_fill_super(). This patch fixes the >> > problem. >> > >> > Reported-by: Pavel Ivanov <paivanof@gmail.com> >> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> >> > Cc: <stable@kernel.org> >> >> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> >> >> Please go ahead and submit the patch. > > That was my patch submission :) > > Christoph, does that work for you, or would you like me to send the > patch in a separate email? Seth, Christoph, I've just found another wrong pointers freeing. The following patch should fix it. Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in hfsplus_read_wrapper() error path Commit 6596528 (hfsplus: ensure bio requests are not smaller than the hardware sectors) changed the pointers used for volume header allocations but failed to change the pointer freed in the error path of hfsplus_read_wrapper(). This patch fixes the problem. Signed-off-by: Pavel Ivanov <paivanof@gmail.com> Cc: <stable@kernel.org> --- diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c index 10e515a..7daf4b8 100644 --- a/fs/hfsplus/wrapper.c +++ b/fs/hfsplus/wrapper.c @@ -272,9 +272,9 @@ reread: return 0; out_free_backup_vhdr: - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_backup_vhdr_buf); out_free_vhdr: - kfree(sbi->s_vhdr); + kfree(sbi->s_vhdr_buf); out: return error; } -- ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod @ 2011-09-11 3:32 ` Pavel Ivanov 0 siblings, 0 replies; 45+ messages in thread From: Pavel Ivanov @ 2011-09-11 3:32 UTC (permalink / raw) To: Hin-Tak Leung, Christoph Hellwig, Pavel Ivanov, linux-fsdevel, linux-kernel On Thu, Sep 8, 2011 at 12:23 PM, Seth Forshee <seth.forshee@canonical.com> wrote: > On Thu, Sep 08, 2011 at 04:13:01AM +0100, Hin-Tak Leung wrote: >> --- On Wed, 7/9/11, Seth Forshee <seth.forshee@canonical.com> wrote: >> >> > Yes, that was definitely just an oversight. Has anyone >> > provided a patch >> > yet? If not I've pasted a patch below. Seems like a fix >> > should be >> > applied ASAP. >> > >> > >> > From d27825b880028e9a45ba640d86c9e8101db0606b Mon Sep 17 >> > 00:00:00 2001 >> > From: Seth Forshee <seth.forshee@canonical.com> >> > Date: Wed, 7 Sep 2011 10:38:35 -0700 >> > Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in >> > hfsplus_fill_super() error path >> > >> > Commit 6596528 (hfsplus: ensure bio requests are not >> > smaller than >> > the hardware sectors) changed the pointers used for volume >> > header >> > allocations but failed to change the pointer freed in the >> > error >> > path of hfsplus_fill_super(). This patch fixes the >> > problem. >> > >> > Reported-by: Pavel Ivanov <paivanof@gmail.com> >> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com> >> > Cc: <stable@kernel.org> >> >> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> >> >> Please go ahead and submit the patch. > > That was my patch submission :) > > Christoph, does that work for you, or would you like me to send the > patch in a separate email? Seth, Christoph, I've just found another wrong pointers freeing. The following patch should fix it. Subject: [PATCH] hfsplus: Fix kfree of wrong pointers in hfsplus_read_wrapper() error path Commit 6596528 (hfsplus: ensure bio requests are not smaller than the hardware sectors) changed the pointers used for volume header allocations but failed to change the pointer freed in the error path of hfsplus_read_wrapper(). This patch fixes the problem. Signed-off-by: Pavel Ivanov <paivanof@gmail.com> Cc: <stable@kernel.org> --- diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c index 10e515a..7daf4b8 100644 --- a/fs/hfsplus/wrapper.c +++ b/fs/hfsplus/wrapper.c @@ -272,9 +272,9 @@ reread: return 0; out_free_backup_vhdr: - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_backup_vhdr_buf); out_free_vhdr: - kfree(sbi->s_vhdr); + kfree(sbi->s_vhdr_buf); out: return error; } -- ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 3:32 ` Pavel Ivanov (?) @ 2011-09-11 14:10 ` Christoph Hellwig 2011-09-12 14:00 ` Pavel Ivanov -1 siblings, 1 reply; 45+ messages in thread From: Christoph Hellwig @ 2011-09-11 14:10 UTC (permalink / raw) To: Pavel Ivanov Cc: Hin-Tak Leung, Christoph Hellwig, linux-fsdevel, linux-kernel, Seth Forshee On Sat, Sep 10, 2011 at 11:32:15PM -0400, Pavel Ivanov wrote: > Seth, Christoph, > > I've just found another wrong pointers freeing. The following patch > should fix it. I'd like to throw this into Seths previous patch, while adding an ACK for your finding. Is that fine with you? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Kernel 3.1.0-rc4 oops when connecting iPod 2011-09-11 14:10 ` Christoph Hellwig @ 2011-09-12 14:00 ` Pavel Ivanov 2011-09-12 15:27 ` [PATCH] hfsplus: Fix kfree of wrong vhdr pointers Seth Forshee 0 siblings, 1 reply; 45+ messages in thread From: Pavel Ivanov @ 2011-09-12 14:00 UTC (permalink / raw) To: Christoph Hellwig Cc: Hin-Tak Leung, Christoph Hellwig, linux-fsdevel, linux-kernel, Seth Forshee On Sun, Sep 11, 2011 at 10:10 AM, Christoph Hellwig <hch@infradead.org> wrote: > On Sat, Sep 10, 2011 at 11:32:15PM -0400, Pavel Ivanov wrote: >> Seth, Christoph, >> >> I've just found another wrong pointers freeing. The following patch >> should fix it. > > I'd like to throw this into Seths previous patch, while adding an > ACK for your finding. Is that fine with you? Yes, that's fine with me. Pavel ^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] hfsplus: Fix kfree of wrong vhdr pointers 2011-09-12 14:00 ` Pavel Ivanov @ 2011-09-12 15:27 ` Seth Forshee 2011-09-12 15:28 ` Christoph Hellwig 0 siblings, 1 reply; 45+ messages in thread From: Seth Forshee @ 2011-09-12 15:27 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-fsdevel, linux-kernel, Pavel Ivanov, Hin-Tak Leung Commit 6596528 (hfsplus: ensure bio requests are not smaller than the hardware sectors) changed the pointers used for volume header allocations, but a couple of spots are still freeing the old pointers. This patch fixes the problem. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Pavel Ivanov <paivanof@gmail.com> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: <stable@kernel.org> --- fs/hfsplus/super.c | 4 ++-- fs/hfsplus/wrapper.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index c106ca2..cadbb8c 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -525,8 +525,8 @@ out_close_cat_tree: out_close_ext_tree: hfs_btree_close(sbi->ext_tree); out_free_vhdr: - kfree(sbi->s_vhdr); - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_vhdr_buf); + kfree(sbi->s_backup_vhdr_buf); out_unload_nls: unload_nls(sbi->nls); unload_nls(nls); diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c index 10e515a..7daf4b8 100644 --- a/fs/hfsplus/wrapper.c +++ b/fs/hfsplus/wrapper.c @@ -272,9 +272,9 @@ reread: return 0; out_free_backup_vhdr: - kfree(sbi->s_backup_vhdr); + kfree(sbi->s_backup_vhdr_buf); out_free_vhdr: - kfree(sbi->s_vhdr); + kfree(sbi->s_vhdr_buf); out: return error; } -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH] hfsplus: Fix kfree of wrong vhdr pointers 2011-09-12 15:27 ` [PATCH] hfsplus: Fix kfree of wrong vhdr pointers Seth Forshee @ 2011-09-12 15:28 ` Christoph Hellwig 0 siblings, 0 replies; 45+ messages in thread From: Christoph Hellwig @ 2011-09-12 15:28 UTC (permalink / raw) To: Seth Forshee Cc: Christoph Hellwig, linux-fsdevel, linux-kernel, Pavel Ivanov, Hin-Tak Leung On Mon, Sep 12, 2011 at 10:27:07AM -0500, Seth Forshee wrote: > Commit 6596528 (hfsplus: ensure bio requests are not smaller than > the hardware sectors) changed the pointers used for volume header > allocations, but a couple of spots are still freeing the old > pointers. This patch fixes the problem. I've already respun the patch to include your Pavel's additional fixes. Just waiting to sort out the size checking issue, and then I will send both things on to Linus. ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2011-09-15 14:35 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-03 3:08 Kernel 3.1.0-rc4 oops when connecting iPod Pavel Ivanov 2011-09-03 3:59 ` Hin-Tak Leung 2011-09-03 3:59 ` Hin-Tak Leung 2011-09-03 4:37 ` Pavel Ivanov 2011-09-03 6:57 ` Hin-Tak Leung 2011-09-03 20:52 ` Pavel Ivanov 2011-09-03 20:52 ` Pavel Ivanov 2011-09-03 23:35 ` Hin-Tak Leung 2011-09-03 23:35 ` Hin-Tak Leung 2011-09-03 23:59 ` Pavel Ivanov 2011-09-03 23:59 ` Pavel Ivanov 2011-09-04 0:37 ` Hin-Tak Leung 2011-09-06 4:35 ` Pavel Ivanov 2011-09-06 4:35 ` Pavel Ivanov 2011-09-06 5:12 ` Hin-Tak Leung 2011-09-06 5:12 ` Hin-Tak Leung 2011-09-06 15:09 ` Pavel Ivanov 2011-09-06 15:09 ` Pavel Ivanov 2011-09-11 3:52 ` Pavel Ivanov 2011-09-11 3:52 ` Pavel Ivanov 2011-09-11 13:46 ` Hin-Tak Leung 2011-09-11 13:46 ` Hin-Tak Leung 2011-09-11 14:14 ` Christoph Hellwig 2011-09-11 14:12 ` Christoph Hellwig 2011-09-12 14:34 ` Christoph Hellwig 2011-09-12 15:19 ` Pavel Ivanov 2011-09-12 15:19 ` Pavel Ivanov 2011-09-12 15:31 ` Christoph Hellwig 2011-09-13 2:20 ` Pavel Ivanov 2011-09-13 2:20 ` Pavel Ivanov 2011-09-14 17:42 ` Christoph Hellwig 2011-09-15 14:35 ` Christoph Hellwig 2011-09-12 15:57 ` Hin-Tak Leung 2011-09-07 17:59 ` Seth Forshee 2011-09-07 17:59 ` Seth Forshee 2011-09-08 3:13 ` Hin-Tak Leung 2011-09-08 3:13 ` Hin-Tak Leung 2011-09-08 16:23 ` Seth Forshee 2011-09-09 12:48 ` Christoph Hellwig 2011-09-11 3:32 ` Pavel Ivanov 2011-09-11 3:32 ` Pavel Ivanov 2011-09-11 14:10 ` Christoph Hellwig 2011-09-12 14:00 ` Pavel Ivanov 2011-09-12 15:27 ` [PATCH] hfsplus: Fix kfree of wrong vhdr pointers Seth Forshee 2011-09-12 15:28 ` Christoph Hellwig
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.