![]() | |||||||||||
Messages in this thread |
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/ | ||||||||||
| Last update: 2005-03-22 14:06 [from the cache] ©2003-2008 | |||||||||||