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