nmount, mountd drops high order MNT_xx flags during a mount update
David Boyd
David.Boyd49 at twc.com
Mon May 11 15:50:32 UTC 2015
On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote:
> Oops, I did my usual and forgot to attach the patch.
>
> Here it is, rick
>
> ----- Original Message -----
> > Doug Rabson wrote:
> > > You could add a single integer-valued vfsopt which holds the
> > > high-order
> > > bits of f_flags?
> > >
> > I have created a patch that does this. It is on
> > https://reviews.freebsd.org/D2506
> > (I have also attached it here, for those who don't use Phabricator.)
> >
> > Please review/comment on this. (Feel free to add yourself as a
> > reviewer, etc.)
> >
> > Also, David, if you can test this patch, it would be appreciated.
> >
> > Thanks for the suggestion Doug, rick
> >
> > > On 7 May 2015 at 02:10, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> > >
> > > > 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
> > > > _______________________________________________
> > > > freebsd-current at freebsd.org mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to
> > > > "freebsd-current-unsubscribe at freebsd.org"
> > > >
> > > _______________________________________________
> > > freebsd-current at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to
> > > "freebsd-current-unsubscribe at freebsd.org"
> > >
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe at freebsd.org"
> >
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
Rick, Edward, et al,
I have applied your patches to several (four) servers and have not
noticed any more instances of the errant behavior.
I think (hope) that this is the correct fix and wonder if this fix might
make it's way into an errata.
Thanks for the quick responses.
David Boyd.
More information about the freebsd-current
mailing list