On Fri, Aug 17, 2001 at 08:43:17AM +0200, Ignatios Souvatzis wrote:
> On Fri, Aug 17, 2001 at 03:25:35PM +1000, Luke Mewburn wrote:
> > I've just committed a fix to sys/ufs/ffs/ffs_bswap.c::ffs_sb_swap()
> > (file rev 1.11) so that mounting opposite-endian file systems using
> > the FFS_EI kernel option should be significantly more stable than
> > it was, especially in the last 8 months.
> 
> what were the problems? I have used opposite-endian filesystems intensively,
> although not in the last 8 months...

try and run a dumpfs binary from before today on an opposite endian
file system ..

ffs_sb_swap() had a third argument - int ns - which was supposed to be
non-zero if the buffer to swap from needed to be swapped and zero if
it was already in host order.

unfortunately, a lot of code in the tree (including in the kernel in
ffs_reload and ffs_mount) incorrectly called ffs_sb_swap() with
'ns=0' for a buffer that needed it ns=1. the effect of this was that
the postbloff field was too large (e.g, 1610940416 instead of 1376).
the kernel would look in never never land to rotate the fs_postbl[].
this wouldn't necessary panic the kernel.  userland would get a segv
if you tried to dumpfs/fsck_ffs/dump a wrong-endian file system.

my fix basically deprecated the ns field and used o->fs_magic to
determine whether or not ffs_sb_swap() needed to swap the values it
uses in its loops. after this change (and modifying all uses of
ffs_sb_swap() to remove the now unnecessary third arg), all the
userland tools started working correctly (instead of dumping core),
and various diagnostic asserts i put in the kernel didn't get tripped
no matter whether i mounted a native or opposite endian file system.

luke.