From: Pavel Ivanov <paivanof@gmail.com> To: Hin-Tak Leung <hintak_leung@yahoo.co.uk> Cc: linux-fsdevel@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: Kernel 3.1.0-rc4 oops when connecting iPod Date: Sat, 3 Sep 2011 19:59:46 -0400 [thread overview] Message-ID: <CAG1a4rscDrbiCKxSPvbkG7SutQ5HCU2tX9FJEv81nFuVxLWekg@mail.gmail.com> (raw) In-Reply-To: <1315092941.97677.YahooMailClassic@web29519.mail.ird.yahoo.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Ivanov <paivanof@gmail.com> To: Hin-Tak Leung <hintak_leung@yahoo.co.uk> Cc: linux-fsdevel@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: Kernel 3.1.0-rc4 oops when connecting iPod Date: Sat, 3 Sep 2011 19:59:46 -0400 [thread overview] Message-ID: <CAG1a4rscDrbiCKxSPvbkG7SutQ5HCU2tX9FJEv81nFuVxLWekg@mail.gmail.com> (raw) In-Reply-To: <1315092941.97677.YahooMailClassic@web29519.mail.ird.yahoo.com> 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
next prev parent reply other threads:[~2011-09-04 0:00 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 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 [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAG1a4rscDrbiCKxSPvbkG7SutQ5HCU2tX9FJEv81nFuVxLWekg@mail.gmail.com \ --to=paivanof@gmail.com \ --cc=hintak_leung@yahoo.co.uk \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.