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

From: Doug Rabson <dfr_at_rabson.org>
Date: Thu, 7 May 2015 07:47:27 +0100
You could add a single integer-valued vfsopt which holds the high-order
bits of f_flags?

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"
>
Received on Thu May 07 2015 - 04:47:34 UTC

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