On Sun, Sep 28, 2003 at 06:20:30PM -0400, Darrin B. Jewell wrote:
> 
> Revision 1.120 of ffs_vfsops dated 2003/09/13 introduced a bug in the
> superblock update code that results in fs_flags having a value of
> 0x7fffff00 after the update.
> 
> Specifically, line 995 of ffs_vfsops.c is this:
>    fs->fs_flags |= (fs->fs_old_flags & ~FS_FLAGS_UPDATED);
> 
> bug since fs_old_flags was int8_t and fs_flags is int32_t, and
> FS_FLAGS_UPDATED is 0x80, the fs_old_flags value gets sign extended
> before it gets copied into fs_flags.  The high bit gets later stripped
> by FS_INTERNAL being forced to zero.  (This behavior also makes me
> nervous, but is tangental to the issue addressed here.)

Why ? Not cleaning up FS_INTERNAL is one of the cause of the compatibility
problems we got.

> 
> Although that line could be updated to remove this problem,
> I think it is a better fix to declare these fields uint8_t and
> uint32_t as per the patch included below.

Yes

> 
> Filesystems that were upgraded by -current kernels in the intermediate
> time will have bad values of fs_flags which will cause a problem which
> will not be exhibited until some future date when those flag fields
> are used.  If desired, I can post a simple program which can go in and
> unset these flags.  Since the lifespan of the incorrect code was
> small, I do not recommend implementing compatibility in the kernel.

Yes, please. And maybe add a warning in the kernel until 2.0 is branched.


-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 23 ans d'experience feront toujours la difference
--