Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262034AbTKGWZK (ORCPT ); Fri, 7 Nov 2003 17:25:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262030AbTKGWYy (ORCPT ); Fri, 7 Nov 2003 17:24:54 -0500 Received: from mx1.elte.hu ([157.181.1.137]:46826 "EHLO mx1.elte.hu") by vger.kernel.org with ESMTP id S264395AbTKGPRi (ORCPT ); Fri, 7 Nov 2003 10:17:38 -0500 Date: Fri, 7 Nov 2003 16:17:29 +0100 (CET) From: Ingo Molnar Reply-To: Ingo Molnar To: Linus Torvalds Cc: Mark Gross , Kernel Mailing List Subject: Re: [PATCH] SMP signal latency fix up. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 925 Lines: 25 On Fri, 7 Nov 2003, Linus Torvalds wrote: > (It _looks_ obvious enough, but can you check that there are no pointers > that we might be following in the "is it running" checks that could be > stale because we don't hold the runqueue lock any more). the 'is it running' check is 'task_curr(p)', which in this circumstance is equivalent to the following test: per_cpu(runqueues, (cpu)).curr == p where 'cpu' is p->thread_info->cpu. All pointers dereferenced in this test are stable, because 1) send_signal() is always called within the siglock, which serializes with task exit 2) p->thread_info->cpu is always valid for the same reason. so this seems to be safe to me. Ingo - 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/