Date: Mon, 29 Mar 2010 22:29:20 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Andriy Gapon <avg@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/emhDCmx8++AioJ8XdIT49uL
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Andriy Gapon <avg@freebsd.org> wrote:
> on 28/03/2010 18:25 Fabian Keil said the following:
> > Andriy Gapon <avg@icyb.net.ua> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100329222920.5eef6395>