From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 20:29:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DBA106566B for ; Mon, 29 Mar 2010 20:29:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by mx1.freebsd.org (Postfix) with ESMTP id 157D38FC12 for ; Mon, 29 Mar 2010 20:29:27 +0000 (UTC) Received: from [87.78.61.127] (helo=r500.local) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NwLaQ-0006G1-C1; Mon, 29 Mar 2010 22:29:26 +0200 Date: Mon, 29 Mar 2010 22:29:20 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20100329222920.5eef6395@r500.local> In-Reply-To: <4BB0A053.9060007@freebsd.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/emhDCmx8++AioJ8XdIT49uL"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:29:28 -0000 --Sig_/emhDCmx8++AioJ8XdIT49uL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 28/03/2010 18:25 Fabian Keil said the following: > > Andriy Gapon wrote: > >> Looking at the code in mountmsdosfs(), it seems that SecPerClust can > >> have zero value at the place of the crash only if pm_BlkPerSec is > >> zero. See this line and the check above it: > >> SecPerClust *=3D pmp->pm_BlkPerSec; > >> But that is impossible because of the same if statement. > >> > >> In my opinion, the only possible explanation is an overflow of a > >> SecPerClust value. Given that its type is u_int8_t, it seems > >> plausible. > >=20 > > That seems to be indeed the case. Adding a printf before > > SecPerClust *=3D pmp->pm_BlkPerSec; > >=20 > > Results in: Multiplying 64 with 8 >=20 > Interesting. See below. >=20 > > Using an unsigned int for SecPerClust allows to mount the file > > system and df -h correctly shows its size, but cd'ing into it > > and running ls -l leads to another panic: >=20 > I that this local workaround cures only one local symptom and pushes the > problem further in the code. The panic you got is a symptom of a deeper > issue. >=20 > Could you please remind us in what way was the filesystem created? > Was it FreeBSD newfs_msdos? Yes. I no longer have the sudo log to see how exactly, but I usually use -F 32 as only option. I no longer have access to the device in question either, but I took an image of the partition and can reproduce the mount issue using mdconfig. Trying to recreate a file system that shows the problem on a file-backed device failed so far. For the dump of the file system with the problem, file says: x86 boot sector, code offset 0x58, OEM-ID "BSD 4.4", Bytes/sector 4096, sectors/cluster 64, heads 255, sectors = =20 3901275 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 60, Backup boot sector 2, serial number 0xc1171b12, unlabeled For the one that doesn't it's: x86 boot sector, code offset 0x58, OEM-ID "BSD4.4 ", sectors/cluster 64, heads 255, sectors 31210200 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 3809, Backup boot sector 2, serial number 0x2e7e19ee, label: "NO_NAME " > I am not a FAT expert and I know to take Wikipedia with a grain of salt. > But please take a look at this: > http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector >=20 > In our formula: > SecPerClust *=3D pmp->pm_BlkPerSec; > we have the following parameters: > SecPerClust[in] - sectors per cluster > pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / > DEV_BSIZE) SecPerClust[out] - bytes per cluster divided by 512 >=20 > So we have: > sectors per cluster: 64 > bytes per sector: 4096 file seems to agree. =20 > That Wikipedia article says: "However, the value must not be such that > the number of bytes per cluster becomes greater than 32 KB." > But in our case it's 256K, the same value that is passed as 'size' > parameter to bread() in the crash stack trace below. >=20 > By the way, that 32KB limit means that value of SecPerClust[out] should > never be greater than 64 and SecPerClust[in] is limited to 128, so its > current must be of sufficient size to hold all allowed values. >=20 > Thus, clearly, it is a fault of a tool that formatted the media for FAT. > It should have picked correct values, or rejected incorrect values if > those were provided as overrides via command line options. The kernel still shouldn't panic, though. Fabian --Sig_/emhDCmx8++AioJ8XdIT49uL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuxDaQACgkQBYqIVf93VJ3PCQCgrGxNNiEURbF6JB1X/UWHSMGn 3ncAnR+FoKlHHFAkRoEcAoWCg7RX812K =1HJV -----END PGP SIGNATURE----- --Sig_/emhDCmx8++AioJ8XdIT49uL--