Messages in this thread | | | Subject | Re: get_current is __pure__, maybe __const__ even | From | Albert Cahalan <> | Date | 15 Sep 2004 23:49:38 -0400 |
| |
On Wed, 2004-09-15 at 22:36, William Lee Irwin III wrote: > On Wed, Sep 15, 2004 at 07:15:18PM -0400, Jakub Jelinek wrote: > >>> current will certainly change in schedule (), > > On Wed, Sep 15, 2004 at 10:10:20PM -0400, Albert Cahalan wrote: > > Not really! > > Yes it does. The interior of schedule() is C and must be compiled also.
Sure. It doesn't matter. The part that matters is all arch-specific assembly.
Hey, the arm port already uses __const__. Unless the arm port is broken, there's proof.
> At some point in the past, I wrote: > >> Why would barrier() not suffice? > > 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().
OK, let's look.
First, there's fork/vfork/clone. At no point does "current" change. A process comes into existance with a ready-made current.
Second, there's sched.c with context_switch(). That does everything via switch_to, like so:
/* Here we just switch the register state and the stack. */ switch_to(prev, next, prev);
No problem. Now I only need to show that switch_to() is safe. Unfortunately, it's arch-specific code. I'll look at a few examples...
x86_64: assembly, and thus OK i386: assembly, and thus OK ppc: assembly, and thus OK arm: already uses __const__ :-)
To find a problem, you need to find an arch which runs C code with current being inconsistent with the stack or registers. That would be wild and evil. In any case, adding __attribute__((__const__)) is an arch-specific change. A truly evil arch running C code with an inconsistent current can just leave off the attribute or, better yet, stop being evil.
- 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/
| |