* 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 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-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 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 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 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 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
* 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
* [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
* 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: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-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
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.