Re: nmount, mountd drops high order MNT_xx flags during a mount update

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sun, 10 May 2015 09:03:25 -0400 (EDT)
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_at_ 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"
> 
Received on Sun May 10 2015 - 11:03:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:57 UTC