From owner-freebsd-bugs Wed Jun 7 23:50:17 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 8415C37BF9D for ; Wed, 7 Jun 2000 23:50:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA88127; Wed, 7 Jun 2000 23:50:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 7 Jun 2000 23:50:05 -0700 (PDT) Message-Id: <200006080650.XAA88127@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: misc/19086: pseudo-device vn doesn't work properly with msdos filesystems Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/19086; it has been noted by GNATS. From: Bruce Evans To: Mark Abene 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 (actually ). - use uint_least32_t from 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