From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Date: Mon, 26 Jul 2004 10:59:45 +0000 Subject: Re: [PATCH] Limit number of concurrent hotplug processes Message-Id: <4104E421.8080700@suse.de> List-Id: References: <40FD23A8.6090409@suse.de> <20040725182006.6c6a36df.akpm@osdl.org> In-Reply-To: <20040725182006.6c6a36df.akpm@osdl.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Andrew Morton Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Andrew Morton wrote: > Hannes Reinecke wrote: >=20 >>the attached patch limits the number of concurrent hotplug processes. >> Main idea behind it is that currently each call to call_usermodehelper=20 >> will result in an execve() of "/sbin/hotplug", without any check whether= =20 >> enough resources are available for successful execution. This leads to=20 >> hotplug being stuck and in worst cases to machines being unable to boot. >> >> This check cannot be implemented in userspace as the resources are=20 >> already taken by the time any resource check can be done; for the same=20 >> reason any 'slim' programs as /sbin/hotplug will only delay the problem. >=20 >=20 > 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? >=20 As Christian Borntraeger already said, it's not so much an explosion of=20 module probes but rather the triggering of quite a lot of events.=20 Imagine loading scsi_debug with 512 devices or more ... >=20 >> Any comments/suggestions welcome; otherwise please apply. >=20 >=20 > I suggest you just use a semaphore, initialised to a suitable value: >=20 >=20 > static struct semaphore foo =3D __SEMAPHORE_INITIALIZER(foo, 50); >=20 >=20 > { > ... > down(&foo); > ... > up(&foo); > ... > } >=20 Hmm; looks good, but: It's not possible to reliably change the maximum=20 number of processes on the fly. The trivial way of course it when the waitqueue is empty and no=20 processes are holding the semaphore. But it's quite non-obvious how this=20 should work if processes are already holding the semaphore. We would need to wait for those processes to finish, setting the length=20 of the queue to 0 (to disallow any other process from grabbing the=20 semaphore), and atomically set the queue length to the new value. Apart from the fact that we would need a worker thread for that=20 (otherwise the calling process might block indefinitely), there is no=20 guarantee that the queue ever will become empty, as hotplug processes=20 might be generated at any time. Or is there an easier way? Cheers, Hannes --=20 Dr. Hannes Reinecke hare@suse.de SuSE Linux AG S390 & zSeries Maxfeldstra=DFe 5 +49 911 74053 688 90409 N=FCrnberg 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=10040&op=CCk _______________________________________________ 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