Date: Wed, 7 Jun 2000 23:50:05 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/19086: pseudo-device vn doesn't work properly with msdos filesystems Message-ID: <200006080650.XAA88127@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/19086; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Mark Abene <phiber@radicalmedia.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: misc/19086: pseudo-device vn doesn't work properly with msdos
filesystems
Date: Thu, 8 Jun 2000 16:47:24 +1000 (EST)
On Wed, 7 Jun 2000, Mark Abene wrote:
> I just did some poking around, and the problem is *not* with the vn driver
> at all, but the msdosfs driver. I just tried mounting a dos floppy and
> tried to read/write it, and ran into the exact same problem with
> "Argument list too long". I have MSDOSFS compiled into the kernel.
> Unfortunately, I don't have 4.0-RELEASE on any Intel boxes, only Alpha.
> I can verify that this problem doesn't exist with 3.4-RELEASE on Intel.
The following quick fix seems to be sufficient on i386's with 64-bit longs:
---
diff -c2 msdosfsmount.h~ msdosfsmount.h
*** msdosfsmount.h~ Thu Jun 8 15:56:37 2000
--- msdosfsmount.h Thu Jun 8 16:01:44 2000
***************
*** 85,89 ****
u_long pm_fatblocksec; /* size of fat blocks in sectors */
u_long pm_fatsize; /* size of fat in bytes */
! u_long pm_fatmask; /* mask to use for fat numbers */
u_long pm_fsinfo; /* fsinfo block number */
u_long pm_nxtfree; /* next free cluster in fsinfo block */
--- 85,89 ----
u_long pm_fatblocksec; /* size of fat blocks in sectors */
u_long pm_fatsize; /* size of fat in bytes */
! u_int32_t pm_fatmask; /* mask to use for fat numbers */
u_long pm_fsinfo; /* fsinfo block number */
u_long pm_nxtfree; /* next free cluster in fsinfo block */
---
pm_fatmask is 0xfff for 12-bit fats, so its complement is 0xfffffffffffff000
on machines with 64-bit longs, so comparisions like
(cn | ~pmp->pm_fatmask) == CLUST_RSRVD) /* CLUST_RSVRD is 0xfffffff6 */
always fail on such machines. The quick fix fixes at least this bug on
machines with ints no larger than 32 bit. The big is subtler on machines
with ints larger than 32 bits. On such machines, u_int32_t has precisely
32 bits, so it must be smaller than int, so in the calculation of its
complement, it will be promoted before taking complements, again giving
too many high bits.
The correct fix is:
- replace ~pmp->pm_fatmask by (~pmp->pm_fatmask & 0xffffffff) everywhere
(actually use a macro instead of 0xffffffff).
- finish implementing <inttypes.h> (actually <stdint.h>).
- use uint_least32_t from <inttypes.h> for pm_fatmask. Don't use u_int32_t,
since it is a deprecated spelling of uint32_t. Don't use uint32_t or
u_long, since they may be pessimal. u_long _is_ pessimal on i386's with
64-bit longs. Similarly for many other types in the kernel.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006080650.XAA88127>