Message-ID: <4148FED6.100@yahoo.com.au>
Date: Thu, 16 Sep 2004 12:47:50 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4
MIME-Version: 1.0
To: William Lee Irwin III <wli@holomorphy.com>
CC: Albert Cahalan <albert@users.sf.net>, Jakub Jelinek <jakub@redhat.com>,
       Albert Cahalan <albert@users.sourceforge.net>,
       linux-kernel mailing list <linux-kernel@vger.kernel.org>, ak@muc.de
Subject: Re: get_current is __pure__, maybe __const__ even
References: <1095288600.1174.5968.camel@cube> <20040915231518.GB31909@devserv.devel.redhat.com> <20040915232956.GE9106@holomorphy.com> <1095300619.2191.6392.camel@cube> <20040916023604.GH9106@holomorphy.com>
In-Reply-To: <20040916023604.GH9106@holomorphy.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 938
Lines: 27

William Lee Irwin III wrote:

> On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote:
> 
>>I don't think even barrier() is needed.
>>Suppose gcc were to cache the value of
>>current over a schedule. Who cares? It'll
>>be the same after schedule() as it was
>>before.
> 
> 
> Not over a call to schedule(). In the midst of schedule().
> 

In a way, it is. Because after context_switch, the stack
and registers have been replaced by the new task. So if
current was cached somewhere before that task had scheduled
off, then it still would be correct now that it is scheduled
back on.

At points *within* context_switch, current won't be right,
but AFAIKS current is never used in there.
-
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/