From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Date: Tue, 27 Jul 2004 09:28:26 +0000 Subject: Re: [PATCH] Limit number of concurrent hotplug processes Message-Id: <20040727022826.2c95d8ff.akpm@osdl.org> List-Id: References: <40FD23A8.6090409@suse.de> <20040725182006.6c6a36df.akpm@osdl.org> <4104E421.8080700@suse.de> <20040726131807.47816576.akpm@osdl.org> <4105FE68.7040506@suse.de> <20040727002409.68d49d7c.akpm@osdl.org> <41060B62.1060806@suse.de> <20040727013427.52d3e5f5.akpm@osdl.org> <41061AC0.8000607@suse.de> In-Reply-To: <41061AC0.8000607@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hannes Reinecke Cc: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Hannes Reinecke 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_id040&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