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: Sat, 3 Sep 2011 07:57:23 +0100 (BST) Message-ID: <1315033043.56167.YahooMailClassic@web29515.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: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org --- 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...) >=20 > Output of this command is in attachment. That's interesting. You said "hfs: filesystem size too large." always a= ppears twice (with kernel 3.1-rc4) before it oops. And in your 2.6.38.1= 1 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/hfs= plus/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 c= aught 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_wrappe= r() was changed in the 2.6.39/3.0 time frame by this: commit 52399b171dfaea02b6944cd6feba49b624147126 Author: Christoph Hellwig Date: Tue Nov 23 14:37:47 2010 +0100 =20 hfsplus: use raw bio access for the volume headers That's code I don't quite understand (I worked on the hfsplus journal c= ode recently, supposedly mentoring for that GSoC project). If you are happy enough to do a bit of experimenting, can you try putti= ng a=20 "if(sbi->s_backup_vhdr)" before line 529? Also it is curious why it wasn't caught in wrapper.c arond 229 to 236 e= nding with: "if (sbi->s_backup_vhdr->signature !=3D sbi->s_vhdr->signature)" The file system too large comes from line 402 in super.c: ----------------------- err =3D 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 tha= t 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...