[RFC] Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls

From: Ian Kent
Date: Thu Mar 13 2008 - 03:15:27 EST


On Thu, 28 Feb 2008, Ian Kent wrote:

> >
> > We seem to be passing some string into a misc-device ioctl and getting some
> > results back. Be aware that this won't be a terribly popular proposal, so
> > I'd suggest that you fully describe the problem which it's trying to solve,
> > and how it solves it, and why the various alternatives (sysfs, netlink,
> > mount options, etc) were judged unsuitable.
>
> Yes, as I said above.
>
> I don't expect that people that aren't close to the development of
> autofs will "get" the problem description in the leading post but I will
> try and expand on it as best I can.
>
> As for the possible alternatives, it sounds like I have some more work
> to do on that. Mount options can't be used as I described in the lead in
> post and, as far as my understanding of sysfs goes, I don't think it's
> appropriate. But, I'm not aware of what the netlink interface may be
> able to do for me so I will need to check on that.
>

I've attempted an implementation of this using the Generic Netlink
interface and I've struck a difficulty. I would like to use current
recommended development policy but I'm not sure how far I should go with
this in order to avoid using an ioctl implementation so I'm after some
advice and suggestions.

So, onto the description.
Sorry about the length of the post.

Autofs user space uses a number of ioctls for mount control.

I have a problem that can only be resolved by adding an additional control
function that doesn't need to open the autofs mount point path directly
to issue ioctl commands. So I decided to re-implement the the control
interface, hopefully, in a cleaner way and solve a couple of other
problems at the same time (by adding two additional control functions
giving a total of three new functions) and improving one of the existing
functions.

My initial proposal used a miscellaneous device to route ioctl commands to
autofs mounts and the question of why current recommended alternatives
were not suitable was asked. The only alternative that may be suitable is
the Netlink interface.

I won't go into the details of the new functions now but focus on the
difficulty I have found implementing one of the existing functions using
the Netlink interface.

There are some restrictions on the scope of the change.
The scope is only the ioctl interface. I don't want change too many things
at once, in particular things that are currently working OK. And I'd like
to retain the existing semantic behavior of the interface.

The function that is a problem is the sending of expire requests. In the
current implementation this function is synchronous. An ioctl is used to
ask the kernel module (autofs4) to check for mounts that can be expired
and, if a candidate is found the module sends a request to the user space
daemon asking it to try and umount the select mount after which the daemon
sends a success or fail status back to the module which marks the
completion of the original ioctl expire request.

The Generic Netlink interface won't allow this because only one concurrent
send request can be active for "all" Generic Netlink Families in use,
since the socket receive function is bracketed by a single mutex. So I would
need to use a workqueue to queue the request but that has it's own set of
problems.

A workqueue can have only one active request going at a time but I may
have a number of concurrent expires happening at any one time and the
request could block for a significant amount of time so I would have to
use multiple queues. Also there isn't a one-to-one correspondence
between autofs super blocks and the stream of expire requests so the
number of needed workqueues isn't known. Hence, a workqueue would need to
be created, used and destroyed for every umount request or some other
elaborate mechanism developed to re-use workqueues. Ideas?

The next issue is that in order to keep track of multiple in flight
requests a separate Netlink socket would need to be opened for every
expire request in order to ensure that the Netlink completion reply makes
it back to the original requesting thread (Is that actually correct?). Not
really such a big problem but it defeats another aim of the
re-implementation, which is to reduce the selinux user space exposure to
file descriptors that are open but don't yet have close-on-exec flag set
when a mount or umount is spawned by the automount daemon. This can
obviously be resolved by adding a mutex around the fork/exec code but
isn't a popular idea due to added performance overhead.

That's about it for a Generic Netlink solution.

It looks like it may be possible to avoid the need to use workqueues by
adding a new netlink protocol. I didn't notice any mutual exclusion
issues in the code but I may not have looked far enough (comments
please?). This approach would still have the issue of needing a new socket
opened for each expire for the tracking multiple requests and a
considerable increase in complexity in the autofs4 module for netlink
communication.

I'm concerned about the effort I would need to devote to make this work
and the increase in complexity that may be needed, especially if the
implementation is ultimately not satisfactory for inclusion in the kernel.

Please help!
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/