Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265276AbUATIj7 (ORCPT ); Tue, 20 Jan 2004 03:39:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265275AbUATIj7 (ORCPT ); Tue, 20 Jan 2004 03:39:59 -0500 Received: from mail-01.iinet.net.au ([203.59.3.33]:45476 "HELO mail.iinet.net.au") by vger.kernel.org with SMTP id S265276AbUATIiW (ORCPT ); Tue, 20 Jan 2004 03:38:22 -0500 Message-ID: <400CE8DC.70307@cyberone.com.au> Date: Tue, 20 Jan 2004 19:37:48 +1100 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030827 Debian/1.4-3 X-Accept-Language: en MIME-Version: 1.0 To: Tim Hockin CC: Rusty Russell , vatsa@in.ibm.com, linux-kernel@vger.kernel.org, torvalds@osdl.org, akpm@osdl.org, rml@tech9.net Subject: Re: CPU Hotplug: Hotplug Script And SIGPWR References: <20040116174446.A2820@in.ibm.com> <20040120060027.91CC717DE5@ozlabs.au.ibm.com> <20040120063316.GA9736@hockin.org> <400CCE2F.2060502@cyberone.com.au> <20040120065207.GA10993@hockin.org> <400CD4B5.6020507@cyberone.com.au> <20040120073032.GB12638@hockin.org> <400CDCA1.5070200@cyberone.com.au> <20040120075409.GA13897@hockin.org> <400CE354.8060300@cyberone.com.au> <20040120082943.GA15733@hockin.org> In-Reply-To: <20040120082943.GA15733@hockin.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1868 Lines: 57 Tim Hockin wrote: >On Tue, Jan 20, 2004 at 07:14:12PM +1100, Nick Piggin wrote: > >>>Under what conditions? Not arbitrary entropy, surely. If a hotplug script >>>is present and does not blow up, it should be safe to assume it will be run >>>upon an event being delivered. If not, we have a WAY bigger problem :) >>> >>> >>That assumption is not safe. The main problems are of course process limits >>and memory allocation failure. >> > >If root has a process limit that make hotplug scripts fail to run, then >we're hosed in a lot of ways. And if we fail to allocate memory, there >really ought to be some retry or something. It seems to me that a failure >to run a hotplug script is a BAD THING. > (or OOM killed being another that comes to mind) It is sometimes inevitable. With that knowledge we should be designing for graceful failure. > >>>Sending it a SIGPWR means you have to run it on a different CPU that it was >>>affined to, which is already a violation. >>> >>At least the task has the option to handle the problem. >> > >But it is a violation of the affinity. As the kernel we CAN NOT know what >the affinity really means. > Not if the application is designed to handle it. How would hotplug scripts make this any different, anyway? > Maybe there is some way for a task to indicate >it would like to receive SIGPWR in that case. Or some other signal. Can we >invent new signals? > >That way a task that KNOWS about the CPU disappearing underneath it can be >wise, while everything else will not just get killed. > Rusty thought you just wouldn't send it unless the process was handling it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/