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, 11 Sep 2011 14:46:08 +0100 (BST) Message-ID: <1315748768.65310.YahooMailClassic@web29513.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 , Christoph Hellwig To: Pavel Ivanov Return-path: Received: from nm9.bullet.mail.ird.yahoo.com ([77.238.189.35]:33234 "HELO nm9.bullet.mail.ird.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754498Ab1IKNqK convert rfc822-to-8bit (ORCPT ); Sun, 11 Sep 2011 09:46:10 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --- On Sun, 11/9/11, Pavel Ivanov wrote: > How about the following patch? >=20 >=20 > Subject: [PATCH] hfsplus: Allow to mount filesystem with > block size > greater than PAGE_SIZE >=20 > 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. >=20 > Signed-off-by: Pavel Ivanov > Cc: > --- >=20 > 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) > =A0=A0=A0 if (!sbi->rsrc_clump_blocks) > =A0=A0=A0 =A0=A0=A0 > sbi->rsrc_clump_blocks =3D 1; >=20 > -=A0=A0=A0 err =3D > generic_check_addressable(sbi->alloc_blksz_shift, > -=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 > =A0=A0=A0 =A0=A0=A0 > sbi->total_blocks); > +=A0=A0=A0 /* > +=A0=A0=A0=A0=A0* Check that filesystem data > can be addressed by sector_t. Obvious way > +=A0=A0=A0=A0=A0* to do that is to call > generic_check_addressable with alloc_blksz_shift > +=A0=A0=A0=A0=A0* and total_blocks as > parameters. But alloc_blksz_shift can be greater > +=A0=A0=A0=A0=A0* than PAGE_SIZE_SHIFT and > in this case it won't be accepted by > +=A0=A0=A0=A0=A0* generic_check_addressable. > s_blocksize_bits will always be accepted > +=A0=A0=A0=A0=A0* and difference between it > and alloc_blksz_shift will be always in > +=A0=A0=A0=A0=A0* fs_shift. > +=A0=A0=A0=A0=A0*/ > +=A0=A0=A0 err =3D > generic_check_addressable(sb->s_blocksize_bits, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 > (u64)sbi->total_blocks << sbi->fs_shift); > =A0=A0=A0 if (err) { > =A0=A0=A0 =A0=A0=A0 printk(KERN_ERR > "hfs: filesystem size too large.\n"); > =A0=A0=A0 =A0=A0=A0 goto out_free_vhdr; Why is the u64 needed? If it is needed, it probably means sbi->total_bl= ocks 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