Could these issues be handled by requiring that looked-up dentries (i.e.
obtained from nfsd_lookup) have the export dentry as an ancester, or is
this too restrictive? If all dentries used in nfsd operations have to
come from nfsd_lookup, it seems like this would keep each operation in
its own export sandbox. Crossing mount points could happen only in
client space then.
> I didn't believe the issue was that serious for so many people; most
> other unices also support just one export per disk. However, it should
> be possible to do this if demand is really huge; but given the
> complications I would leave things the way for now until the rest
> works. (Except for restoring the pre-dentry checks for .. lookups. This
> is really a big security issue).
OK, I'll put this off for now.
> A quite different things also having to do with exports is that people
> have been complaining early on that when they export /mnt/cdrom they
> can't unmount the cdrom anymore... I'm not sure how that could be
> fixed.
I've been thinking about this, and one possibility would be to create a
registration list for each mount. Then at umount time the system could
call an unregister function for each element on the list. If possible,
the resource would be freed and the list element removed. If the list
became empty, the umount would proceed, otherwise it would fail with
EBUSY.
Right now I can't think of anything except knfsd that needs something
like this, but it would be applicable to any system needing to cache
use-counted fs resources.
Regards,
Bill