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

* Ian Kent <raven@xxxxxxxxxx> 2008-03-13 16:00
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.

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.

Netlink is a messaging protocol, synchronization is up to the user.

I suggest that you send a netlink notification to a multicast group for
every expire candiate when an expire request is received. Unmount
daemons simply subscribe to the group and wait for work to do. Put the
request onto a list including the netlink pid and sequence number so you
can address the orignal source of the request later on. Exit the netlink
receive function and wait for the userspace daemon to get back to you.

The userspace daemon notifies you of successful or unsuccesful unmount
attempts by sending notifications. Update your list entry accordingly
and once the request is fullfilled send a notification to the original
source of the request by using the stored pid and sequence number.

The userspace application requesting the expire can simply block on the
receival of this notification in order to make the whole operation
synchronous.

Sounds acceptable?
--
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/

Relevant Pages