Re: [PATCH] Limit number of concurrent hotplug processes

[Andrew Morton]

Hannes Reinecke <hare@xxxxxxx> 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.
-
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/