Cc: Kernel Mailing List <linux-kernel@...>, autofs mailing list <autofs@...>, linux-fsdevel <linux-fsdevel@...>, Christoph Hellwig <hch@...>, Al Viro <viro@...>, Thomas Graf <tgraf@...>
I've spent several weeks on this now and I'm having considerable
difficulty with the expire function.
First, I think using a raw netlink implementation defeats the point of
using this approach at all due to increased complexity. So I've used the
generic netlink facility and the libnl library for user space. While the
complexity on the kernel side is acceptable that isn't the case in user
space, the code for the library to issue mount point control commands has
more than doubled in size and is still not working for mount point
expiration. This has been made more difficult because libnl isn't
thread safe, but I have overcome this limitation for everything but
the expire function, I now can't determine whether the problem I have with
receiving multicast messages, possibly out of order, on individual
netlink sockets opened specifically for this purpose, is due to this or is
something I'm doing wrong.
The generic netlink implementation allows only one message to be in flight
at a time. But my expire selects an expire candidate (if possible), sends
a request to the daemon to do the umount, obtains the result status and
returns this as the result to the original expire request. Consequently, I
need to spawn a kernel thread to do this and return, then listen for the
matching multicast message containing the result. I don't particularly
like spawning a thread to do this because it opens the possibility of
orphaned threads which introduces other difficulties cleaning them up if
the user space application goes away or misbehaves. But I'm also having
problems catching the multicast messages. This works fine in normal
operation but fails badly when I have multiple concurrent expires
happening, such as when shutting down the daemon with several hundred
active mounts. I can't avoid the fact that netlink doesn't provide the
same functionality as the ioctl interface and clearly isn't meant to.
So, the question is, what are the criteria to use for deciding that a
netlink based implementation isn't appropriate because I think I'm well
past it now?
Comments please.
Ian
--
