linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Limit number of concurrent hotplug processes
Date: Mon, 26 Jul 2004 10:59:45 +0000	[thread overview]
Message-ID: <4104E421.8080700@suse.de> (raw)
In-Reply-To: <20040725182006.6c6a36df.akpm@osdl.org>

Andrew Morton wrote:
> Hannes Reinecke <hare@suse.de> wrote:
> 
>>the attached patch limits the number of concurrent hotplug processes.
>> Main idea behind it is that currently each call to call_usermodehelper 
>> will result in an execve() of "/sbin/hotplug", without any check whether 
>> enough resources are available for successful execution. This leads to 
>> hotplug being stuck and in worst cases to machines being unable to boot.
>>
>> This check cannot be implemented in userspace as the resources are 
>> already taken by the time any resource check can be done; for the same 
>> reason any 'slim' programs as /sbin/hotplug will only delay the problem.
> 
> 
> hm, it's a bit sad that this happens.  Are you able to tell us more about
> what is causing such an explosion of module probes?
> 
As Christian Borntraeger already said, it's not so much an explosion of 
module probes but rather the triggering of quite a lot of events. 
Imagine loading scsi_debug with 512 devices or more ...

> 
>> Any comments/suggestions welcome; otherwise please apply.
> 
> 
> I suggest you just use a semaphore, initialised to a suitable value:
> 
> 
> static struct semaphore foo = __SEMAPHORE_INITIALIZER(foo, 50);
> 
> 
> {
> 	...
> 	down(&foo);
> 	...
> 	up(&foo);
> 	...
> }
> 
Hmm; looks good, but: It's not possible to reliably change the maximum 
number of processes on the fly.

The trivial way of course it when the waitqueue is empty and no 
processes are holding the semaphore. But it's quite non-obvious how this 
should work if processes are already holding the semaphore.
We would need to wait for those processes to finish, setting the length 
of the queue to 0 (to disallow any other process from grabbing the 
semaphore), and atomically set the queue length to the new value.
Apart from the fact that we would need a worker thread for that 
(otherwise the calling process might block indefinitely), there is no 
guarantee that the queue ever will become empty, as hotplug processes 
might be generated at any time.

Or is there an easier way?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
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Ìk
_______________________________________________
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

  parent reply	other threads:[~2004-07-26 10:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-20 13:52 [PATCH] Limit number of concurrent hotplug processes Hannes Reinecke
2004-07-26  1:20 ` Andrew Morton
2004-07-26  6:19   ` Christian Borntraeger
2004-07-26 10:59   ` Hannes Reinecke [this message]
2004-07-26 20:18     ` Andrew Morton
2004-07-27  7:04       ` Hannes Reinecke
2004-07-27  7:24         ` Andrew Morton
2004-07-27  7:59           ` Hannes Reinecke
2004-07-27  8:34             ` Andrew Morton
2004-07-27  9:05               ` Hannes Reinecke
2004-07-27  9:28                 ` Andrew Morton
2004-07-27 12:22                   ` Hannes Reinecke
2004-07-28  7:12                   ` Paul Jackson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=4104E421.8080700@suse.de \
    --to=hare@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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