Re: newfs_msdos and DVD-RAM

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