nmount, mountd drops high order MNT_xx flags during a mount update
Rick Macklem
rmacklem at uoguelph.ca
Thu May 7 01:10:06 UTC 2015
David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED
flag getting cleared by mountd.
http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
I just took a look at this and it's kinda ugly...
mountd acquires a list of mounts via getmntinfo() and then does an
nmount() for each of them to get rid of any exports. It uses
f_flags from the statfs returned by getmntinfo() as the 3rd
argument to nmount().
--> Since nmount()s 3rd argument is a "int", it silently drops any
MNT_xx flag in the high order 32bits of f_flags. At this time,
it happens that MNT_AUTOMOUNTED is the only one, but...
I can think of a couple of ways to fix this, but I don't like any of
them;-)
1) I suppose mountd could check for each flag set in f_flags and generate
a vfsopts string for it, but that means that every time a new flag that
can be updated is added to MNT_xx, this mountd.c code would have to updated.
--> Ugly!!
2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits.
I wouldn`t mind this except in means that the MNT_xx flags must be redefined
and I don`t think that could get MFC`d.
3) Add a new newernmount(2) which has a 64bit flags argument instead of int.
Hopefully someone can think of a nice way to fix this, rick
More information about the freebsd-current
mailing list