LKML Archive on
help / color / mirror / Atom feed
From: Ian Kent <>
To: Thomas Graf <>
Cc: Kernel Mailing List <>,
	Andrew Morton <>,
	autofs mailing list <>,
	linux-fsdevel <>,
	Christoph Hellwig <>, Al Viro <>
Subject: Re: [RFC] Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
Date: Fri, 14 Mar 2008 23:10:11 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 2008-03-14 at 13:45 +0100, Thomas Graf wrote:
> * Ian Kent <> 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.

Yes, I realize that, but what I'm curious about are the options that I
have within the messaging system to control delivery of message replies,
other than using separate sockets. Can this be achieved by using the pid
set in the originating message?

> 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.

I'll have to think about what you've said here to relate it to the
situation I have. I don't actually have umount daemons, at the moment I
request an expire and the daemon creates a thread to do the umount and
sends a status message to the kernel module. But that may not matter,
see below.

> 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.

Actually, I've progressed on this since posting.

I've implemented the first steps toward using a workqueue to perform the
expire and, to my surprise, my code worked for a simple test case.
Basically, a thread in the daemon issues the expire, the kernel module
queues the work and replies. The expire workqueue task does the expire
check and if no candidates are found it sends an expire complete
notification, or it sends a umount request to the daemon and waits for
the status result, then returns that result as the expire compete
notification. Seems to work quite well.

I expect this is possibly the method you're suggesting above anyway.

Unfortunately, having now stepped up intensity of the testing, I'm
getting a hard hang on my system. I've setup to reduce the message
functions used to only two simple notification messages to the kernel
module to ensure it isn't the expire implementation causing the problem.
It's hard to see where I could have messed these two functions as they
are essentially re-entrant but there is fairly heavy mount activity of
about 10-15 mounts a second. Such is life!

Any ideas on what might be causing this?


  reply	other threads:[~2008-03-14 14:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26  3:21 [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Ian Kent
2008-02-26  3:22 ` [PATCH 1/4] autofs4 - check for invalid dentry in getpath Ian Kent
2008-02-26  3:23 ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Ian Kent
2008-02-26  5:14   ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor - correction Ian Kent
2008-02-28  4:45   ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Andrew Morton
2008-02-28  6:22     ` Ian Kent
2008-02-28  6:37       ` Andrew Morton
2008-02-28  7:08         ` Ian Kent
2008-02-28  7:23           ` Andrew Morton
2008-02-28  8:00             ` Ian Kent
2008-02-28 17:13               ` Jeff Moyer
2008-02-28 19:51                 ` Serge E. Hallyn
2008-02-29  3:32                   ` Ian Kent
2008-02-29 16:09                     ` Serge E. Hallyn
2008-02-29 16:20                       ` Pavel Emelyanov
2008-02-29 17:42                         ` Serge E. Hallyn
2008-03-02  0:49                       ` Eric W. Biederman
2008-03-02  1:13                       ` Eric W. Biederman
2008-03-03 15:28                         ` Serge E. Hallyn
2008-03-04 22:16                           ` Eric W. Biederman
2008-02-28  7:51           ` Pavel Emelyanov
2008-02-28  7:59             ` Andrew Morton
2008-02-28  8:06               ` Ian Kent
2008-02-28 12:31                 ` [autofs] " Fabio Olive Leite
2008-02-28 20:33             ` Eric W. Biederman
2008-02-26  3:23 ` [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  6:18     ` Ian Kent
2008-03-13  7:00       ` [RFC] " Ian Kent
2008-03-14  2:45         ` Ian Kent
2008-03-14 12:45         ` Thomas Graf
2008-03-14 14:10           ` Ian Kent [this message]
2008-02-29 16:24     ` Ian Kent
2008-04-11  7:02       ` Ian Kent
2008-04-12  4:03         ` Andrew Morton
2008-04-14  4:45           ` Ian Kent
2008-02-26  4:29 ` [PATCH 2/4] autofs4 - add mount option to display mount device Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  4:40 ` [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Andrew Morton
2008-02-28  6:07   ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).