From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760791AbZBLUtp (ORCPT ); Thu, 12 Feb 2009 15:49:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758901AbZBLUtg (ORCPT ); Thu, 12 Feb 2009 15:49:36 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:47582 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758620AbZBLUtf (ORCPT ); Thu, 12 Feb 2009 15:49:35 -0500 Date: Thu, 12 Feb 2009 12:48:35 -0800 From: Andrew Morton To: ebiederm@xmission.com (Eric W. Biederman) Cc: fweisbec@gmail.com, mingo@elte.hu, linux-kernel@vger.kernel.org, oleg@redhat.com, travis@sgi.com, a.p.zijlstra@chello.nl, mm-commits@vger.kernel.org, rusty@rustcorp.com.au Subject: Re: + work_on_cpu-rewrite-it-to-create-a-kernel-thread-on-demand.patch added to -mm tree Message-Id: <20090212124835.2fc41620.akpm@linux-foundation.org> In-Reply-To: References: <200902031058.n13AwOoK016719@imap1.linux-foundation.org> <20090203121147.GB19979@elte.hu> <20090203112529.26e6bf76.akpm@linux-foundation.org> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 12 Feb 2009 12:38:36 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote: > Andrew Morton writes: > > > > Series of four patches: > > > > - switch cstate.c frmo work_on_cpu to smp_call_function_single() > > > > - ditto acpi-cpufreq.c > > > > - ditto mce_amd_64.c > > > > The final work_on_cpu() caller is pci_call_probe(). I'd like to find a > > way of removing that callsite as well, so we can finally remove this > > turkey but for now, just fix the bugs in it: > > As far as I can tell when we are doing the probes we are in a function > that can sleep, so we should be able to just call set_cpus_allowed to > remove the need for work_on_cpu in pci_call_probe. Possibly with a > save/restore of the allowed cpus. > > Am I missing something? > The problem with set_cpus_allowed() is that some other suitably-privileged userspace process can come in from the side and modify your cpus_allowed at any time.