From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 12:43:04 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 743C7106566B for ; Mon, 29 Mar 2010 12:43:04 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 99DE88FC17 for ; Mon, 29 Mar 2010 12:43:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27219; Mon, 29 Mar 2010 15:42:59 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB0A053.9060007@freebsd.org> Date: Mon, 29 Mar 2010 15:42:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Fabian Keil 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> In-Reply-To: <20100328172537.501ed3d1@r500.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 12:43:04 -0000 If you want to make sure that I see your reply please include me into recipient list. FreeBSD mailing lists sometimes have high volume and it's easy to miss a followup even if you are interested in reading it. 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 *= 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? 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 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. > fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 [snip] > Unread portion of the kernel message buffer: > panic: getblk: size(262144) > MAXBSIZE(65536) [snip] > #11 0xffffffff803bedfb in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:562 > #12 0xffffffff8042ecde in getblk (vp=0xffffff006dbfad20, blkno=992, size=262144, slpflag=0, slptimeo=Variable "slptimeo" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:2523 > #13 0xffffffff8042f12f in breadn (vp=0xffffff006dbfad20, blkno=Variable "blkno" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:800 > #14 0xffffffff8042f24e in bread (vp=Variable "vp" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:748 > #15 0xffffffff8035efc2 in msdosfs_readdir (ap=0xffffff803e71ca60) at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:1641 [snip] -- Andriy Gapon