From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hin-Tak Leung Subject: Re: Kernel 3.1.0-rc4 oops when connecting iPod Date: Sun, 4 Sep 2011 00:35:41 +0100 (BST) Message-ID: <1315092941.97677.YahooMailClassic@web29519.mail.ird.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, linux-kernel To: Pavel Ivanov Return-path: Received: from nm5-vm0.bullet.mail.ird.yahoo.com ([77.238.189.207]:20650 "HELO nm5-vm0.bullet.mail.ird.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752318Ab1ICXfo convert rfc822-to-8bit (ORCPT ); Sat, 3 Sep 2011 19:35:44 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --- On Sat, 3/9/11, Pavel Ivanov wrote: > Hin-Tak, >=20 > "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: >=20 > out_free_vhdr: > =A0=A0=A0 printk(KERN_ERR "hfs: sbi->s_vhdr =3D > %p, sbi->s_backup_vhdr =3D %p\n", > sbi->s_vhdr, sbi->s_backup_vhdr); > =A0=A0=A0 kfree(sbi->s_vhdr); > =A0=A0=A0 kfree(sbi->s_backup_vhdr); >=20 > And here's what I see after connecting an iPod: >=20 > [=A0=A0=A092.549197] hfs: filesystem size too > large blksz_shift=3D14, > total_blocks=3D486494 > [=A0=A0=A092.635714] hfs: sbi->s_vhdr =3D > ffff88013703a690, sbi->s_backup_vhdr > =3D ffff88013703e268 > [=A0=A0=A092.730543] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [=A0=A0=A092.828425] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703a690 > ... > [=A0=A0=A093.213890] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [=A0=A0=A093.311834] BUG kmalloc-4096: Invalid > object pointer 0xffff88013703e268 > ... > [=A0=A0=A093.868618] hfs: filesystem size too > large blksz_shift=3D14, > total_blocks=3D486494 > [=A0=A0=A093.955327] hfs: sbi->s_vhdr =3D > ffff8801343c37d8, sbi->s_backup_vhdr > =3D ffff8801343c5120 > [=A0=A0=A094.050133] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [=A0=A0=A094.148026] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c37d8 > ... > [=A0=A0=A094.533895] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [=A0=A0=A094.631746] BUG kmalloc-4096: Invalid > object pointer 0xffff8801343c5120 >=20 >=20 > So these 2 pointers are exactly what causing the trouble. This is interesting... so it would appear that hfsplus_read_wrapper() i= sn't working correctly, but enough of correct information to pass check= s. 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 51= 2... you will need to look into hfsplus_submit_bio(), which is in the s= ame file wrapper.c.=20 It is going to be difficult to do anything without the actual device an= d 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 a= sk you to send me say, the first few MB of the disk? I guess something = like this: dd if=3D/dev/sdb of=3Ddiskfile-sdb ibs=3D4096 count=3D512 dd if=3D/dev/sdb1 of=3Ddiskfile-sdb1 ibs=3D4096 count=3D512 dd if=3D/dev/sdb2 of=3Ddiskfile-sdb2 ibs=3D4096 count=3D512 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 tho= ugh - it could do some serious damage if not carefully used. =20 > On Sat, Sep 3, 2011 at 2:57 AM, Hin-Tak Leung > wrote: > > --- On Sat, 3/9/11, Pavel Ivanov > wrote: > > > >> On Fri, Sep 2, 2011 at 11:59 PM, > >> Hin-Tak Leung > >> 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=3Dy. > 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 =A0-A 1000 > >> '' > >> > (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: =A0 =A0 =A0 =A0kfree(sbi->s_vhdr); > > 529: =A0 =A0 =A0 =A0kfree(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: > > > > =A0 =A0commit 52399b171dfaea02b6944cd6feba49b624147126 > > =A0 =A0Author: Christoph Hellwig > > =A0 =A0Date: =A0 Tue Nov 23 14:37:47 2010 +0100 > > > > =A0 =A0 =A0 =A0hfsplus: 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 !=3D > sbi->s_vhdr->signature)" > > > > > > The file system too large comes from line 402 in > super.c: > > ----------------------- > > =A0 =A0 =A0 =A0err =3D > generic_check_addressable(sbi->alloc_blksz_shift, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 > =A0 =A0sbi->total_blocks); > > =A0 =A0 =A0 =A0if (err) { > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "hfs: > filesystem size too large.\n"); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto 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=3D%d, total_blocks=3D%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... > > > > > > > > >=20 -- 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