on 30/03/2010 18:41 Andriy Gapon said the following:
> on 30/03/2010 18:36 Fabian Keil said the following:
>> Andriy Gapon <a...@freebsd.org> wrote:
>>
>>> on 29/03/2010 23:29 Fabian Keil said the following:
>>>> Andriy Gapon <a...@freebsd.org> wrote:
>>>>> 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.
>>> A quick reply to this point only - yes, I completely agree.
>>> But remember that the panic happened only after the sources were modified :)
>> It wasn't clear from my message, but I was mainly referring to the
>> division-by-zero panic mentioned at the beginning of the thread,
>> for which I posted a work-around in <20100319191133.46fe2...@r500.local>.
>
> Oh, yes, right.
To clarify - I already forgot that the original problem was division by zero
panic
and for some reason thought that it was EINVAL.
Anyways, here is a patch that I would use.
Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
--- a/sys/fs/msdosfs/msdosfs_vfsops.c
+++ b/sys/fs/msdosfs/msdosfs_vfsops.c
@@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp)
|| (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1))
|| (pmp->pm_HugeSectors == 0)
|| (pmp->pm_FATsecs == 0)
+ || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE)
) {
error = EINVAL;
goto error_exit;
--
Andriy Gapon
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
