Date: Thu, 13 Mar 2008 16:00:38 +0900 (WST)
From: Ian Kent <raven@themaw.net>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
cc: Andrew Morton <akpm@linux-foundation.org>,
       autofs mailing list <autofs@linux.kernel.org>,
       linux-fsdevel <linux-fsdevel@vger.kernel.org>,
       Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk>
Subject: [RFC] Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
In-Reply-To: <1204179539.3501.17.camel@raven.themaw.net>
Message-ID: <Pine.LNX.4.64.0803131408460.4608@raven.themaw.net>
References: <Pine.LNX.4.64.0802261151400.8490@raven.themaw.net> 
 <Pine.LNX.4.64.0802261218230.8490@raven.themaw.net> 
 <20080227211723.d5d27c09.akpm@linux-foundation.org> <1204179539.3501.17.camel@raven.themaw.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5554
Lines: 110

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/