Date: Wed, 6 May 2015 21:10:04 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: freebsd current <freebsd-current@freebsd.org> Cc: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@freebsd.org>, David.Boyd49@twc.com Subject: nmount, mountd drops high order MNT_xx flags during a mount update Message-ID: <1588878108.33116674.1430961004678.JavaMail.root@uoguelph.ca>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1588878108.33116674.1430961004678.JavaMail.root>