Recent reports of a failure to find a direct mount map entry on lookup

Hi David,

Here is the patch series I currently have for this problem.

I've also tried to describe the cases I think are at play and if they
are resolved by the series as well as the case I think is problematic.

Please feel free to use these in any way that is useful and any thoughts
or improvements are welcome.

The little evidence I have related to this problem indicates it is
related to updating (re-reading) autofs mount maps. Review of the
source code surrounding this map updating shows there are a number
of cases.

Indirect mount map entries are far more tolerant of map updates than
direct mount maps. The reports I have are related to direct mount maps
so that has been the focus of the code review.

An autofs direct mount can have multiple entries in the master map and
therefore can consist of multiple maps. So the same direct map entry
path can be removed from one map and added to another in the same
update.

This is one case that needs to be handled and problems with this case
should be fixed by the patches resulting from the code review.

Another case is where a map entry is removed but has a triggered mount
covering it. Fixes for this case should also be covered buy the patches
here.

The third case is where a map entry is removed from a map, there are no
other instances of it, there's no real mount associated with it, but the
direct mount trigger mount remains mounted following the map update.
This allows the kernel to send a mount request for a map entry that
doesn't exist. It results in a fatal error because automount(8) doesn't
have a way to communicate the failure to the kernel as there's no ioctl
file handle to do so.

This is I think the case that's been seen here and upstream and remains
unresolved.

So far I have been unable to work out how a mount trigger can be left
mounted when a map entry is removed. As a workaround I have improved the
handling of this case in the mount request code. It now uses a method
similar to the that used to reconnect to existing mounts at startup to
open a file handle to send the failure status to the kernel (the last
two patches). While this method should work almost all of the time it
can still fail so I still need to work out why the direct mount trigger
isn't being umounted on map entry removal.

Ian