kern/165559: [ufs] [patch] ufsmount.h uses the 'export' keyword as a structure member name

Bruce Evans brde at optusnet.com.au
Thu Mar 1 11:05:17 UTC 2012


On Thu, 1 Mar 2012, Konstantin Belousov wrote:

> On Thu, Mar 01, 2012 at 01:08:49PM +1100, Bruce Evans wrote:
>> ...
>> To summarise, even ffs utilities should be using this header.  There are
>> 1 or 2 ffs utilities that can reasonably use it, and a few non-ffs
>> utilities that use since they haven't been converted to nmount().  amd
>> is the only significant remaining one.
>>
> Yes.

amd seems to have no references to `export' (it does have references to
fspec).  Thus the problem is very small.

> I expect the bug submitter to finish the work and provide a complete
> patch for renaming.

That's asking a lot.

> FWIW, the export_ is ugly, some reasonable name should be used.

It could probably be renamed to `foo', or better yet, to `ugly' for
userland only, and almost nothing would notice (I only noticed fsck_ffs
accessing it, and that access was bogus (better done with bzero()) and
went away with conversion to nmount()).

Of course, the correct name is something like fa_export (fa = ffs args).

In old mount(8), args.export was only used to initialize
args.export.ex_root to DEFAULT_ROOTUID = -2 (uids can't be negative and
this gets type-punned to 0xfffffffe) and args.export.ex_flags to
either MNT_EXRDONLY or to 0 depending on whether the mount is r/o.
I wonder how this works now.  Current mount code doesn't pass "export"
and doesn't define DEFAULT_ROOTUID.  mountd still has a more-magic -2.
and OP_MAPROOT to change it.  Other callers of mount() didn't bother
to set DEFAULT_ROOTUID or MNT_EXRDONLY.  One in fsck_ffs even seems
to pass stack garbage for the entire args.export.  df still uses mount()
and a ufs_args struct.  It doesn't bother setting anything, but doesn't
pass stack garbage since it uses a static args struct.

Bruce


More information about the freebsd-fs mailing list