newfs_msdos and DVD-RAM
Fabian Keil
freebsd-listen at fabiankeil.de
Mon Mar 29 20:29:28 UTC 2010
Andriy Gapon <avg at freebsd.org> wrote:
> on 28/03/2010 18:25 Fabian Keil said the following:
> > Andriy Gapon <avg at 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 *= 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.
> >
> > That seems to be indeed the case. Adding a printf before
> > SecPerClust *= pmp->pm_BlkPerSec;
> >
> > Results in: Multiplying 64 with 8
>
> Interesting. See below.
>
> > 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:
>
> 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.
>
> 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
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
>
> In our formula:
> SecPerClust *= 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
>
> So we have:
> sectors per cluster: 64
> bytes per sector: 4096
file seems to agree.
> 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.
>
> 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.
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100329/fec2d329/signature.pgp
More information about the freebsd-current
mailing list