lkml.org 
[lkml]   [2011]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel 3.1.0-rc4 oops when connecting iPod
    --- 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...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-09-04 02:39    [W:2.613 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site