Re: [PATCH] Limit number of concurrent hotplug processes

[Andrew Morton <akpm@osdl.org>]

Hannes Reinecke <hare@suse.de> wrote:
>
>  Problem with your patch is that call_usermodehelper might block on 
>  down() regardless whether it is called async or sync.
>  So any write to sysfs which triggers a hotplug event might block until 
>  enough resources are available.

This is exactly the behaviour we want.  If we don't block the caller then
the only option is to fail the call_usermodehelper() attempt, which would
be very bad indeed.

The main reason for calling call_usermodehelper(wait=0) is that the caller
holds locks which will prevent the helper application from terminating.  I
guess my proto-patch risks the same deadlock, because all the
currently-running helpers may be waiting on that lock.

Maybe this is why you were allocating a copy of the call_usermodehelper()
arguments?  I didn't try to reverse-engineer your patch to that extent -
I'd prefer to hear the design in your own words.  Am still waiting for
this, btw.

Allocating a whole bunch of buffers to hold copies of the
call_usermodehelper() args also uses resources, of course.  But it should
be acceptable.  We'd allocate the same amount of memory if we were sending
messages up a socket/pipe to userspace, which is what we should always have
done, instead of the direct-exec - it's caused tons of trouble.

You didn't answer half the questions in my previous email, btw.

Right now, I cannot think of any solution apart from:

- In the sync path, take the semaphore

- In the async path, take a copy of the args, then pass them over to some
  kernel thread which takes the args off a list one-at-a-time, takes the
  semaphore for each one, execs the helper and drops the semaphore on the
  exit path.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel