Fix some bugs involving the fsinfo block (many remain unfixed). This is

part of fixing msdosfs for large sector sizes.  One of the fixed bugs
was fatal for large sector sizes.

1. The fsinfo block has size 512, but it was misunderstood and declared
   as having size 1024, with nothing in the second 512 bytes except a
   signature at the end.  The second 512 bytes actually normally (if
   the file system was created by Windows) consist of a second boot
   sector which is normally (in WinXP) empty except for a signature --
   the normal layout is one boot sector, one fsinfo sector, another
   boot sector, then these 3 sectors duplicated.  However, other
   layouts are valid.  newfs_msdos produces a valid layout with one
   boot sector, one fsinfo sector, then these 2 sectors duplicated.
   The signature check for the extra part of the fsinfo was thus
   normally checking the signature in either the second boot sector
   or the first boot sector in the copy, and thus accidentally
   succeeding.  The extra signature check would just fail for weirder
   layouts with 512-byte sectors, and for normal layouts with any other
   sector size.

   Remove the extra bytes and the extra signature check.

2. Old versions did i/o to the fsinfo block using size 1024, with the
   second half only used for the extra signature check on read.  This
   was harmless for sector size 512, and worked accidentally for sector
   size 1024.  The i/o just failed for larger sector sizes.

   The version being fixed did i/o to the fsinfo block using size
   fsi_size(pmp) = (1024 << ((pmp)->pm_BlkPerSec >> 2)).  This
   expression makes no sense.  It happens to work for sector small
   sector sizes, but for sector size 32K it gives the preposterous
   value of 64M and thus causes panics.  A sector size of 32768 is
   necessary for at least some DVD-RW's (where the minimum write size
   is 32768 although the minimum read size is 2048).

   Now that the size of the fsinfo block is 512, it always fits in
   one sector so there is no need for a macro to express it.  Just
   use the sector size where the old code uses 1024.

Approved by:	re (kensmith)
Approved by:	nyan (several years ago for a different version of (2))
This commit is contained in:
Bruce Evans 2007-07-12 16:09:07 +00:00
parent eb8e82f5fd
commit fd7c4230b2
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=171406
4 changed files with 3 additions and 12 deletions

View file

@ -167,6 +167,4 @@ struct fsinfo {
u_int8_t fsinxtfree[4];
u_int8_t fsifill2[12];
u_int8_t fsisig3[4];
u_int8_t fsifill3[508];
u_int8_t fsisig4[4];
};

View file

@ -376,7 +376,7 @@ updatefats(pmp, bp, fatbn)
+ ffs(pmp->pm_inusemap[cn / N_INUSEBITS]
^ (u_int)-1) - 1;
}
if (bread(pmp->pm_devvp, pmp->pm_fsinfo, fsi_size(pmp),
if (bread(pmp->pm_devvp, pmp->pm_fsinfo, pmp->pm_bpcluster,
NOCRED, &bpn) != 0) {
/*
* Ignore the error, but turn off FSInfo update for the future.

View file

@ -644,14 +644,13 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp, struct thread *td)
if (pmp->pm_fsinfo) {
struct fsinfo *fp;
if ((error = bread(devvp, pmp->pm_fsinfo, fsi_size(pmp),
if ((error = bread(devvp, pmp->pm_fsinfo, pmp->pm_bpcluster,
NOCRED, &bp)) != 0)
goto error_exit;
fp = (struct fsinfo *)bp->b_data;
if (!bcmp(fp->fsisig1, "RRaA", 4)
&& !bcmp(fp->fsisig2, "rrAa", 4)
&& !bcmp(fp->fsisig3, "\0\0\125\252", 4)
&& !bcmp(fp->fsisig4, "\0\0\125\252", 4)) {
&& !bcmp(fp->fsisig3, "\0\0\125\252", 4)) {
pmp->pm_nxtfree = getulong(fp->fsinxtfree);
if (pmp->pm_nxtfree == 0xffffffff)
pmp->pm_nxtfree = CLUST_FIRST;

View file

@ -210,12 +210,6 @@ struct msdosfs_fileno {
? roottobn((pmp), (dirofs)) \
: cntobn((pmp), (dirclu)))
/*
* Calculate fsinfo block size
*/
#define fsi_size(pmp) \
(1024 << ((pmp)->pm_BlkPerSec >> 2))
void msdosfs_fileno_init(struct mount *);
void msdosfs_fileno_free(struct mount *);
uint32_t msdosfs_fileno_map(struct mount *, uint64_t);