[lkml]   [2001]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: VM-related Oops: 2.4.15pre1
In article <20011118073730.C25232@athlon.random>,
Andrea Arcangeli <> wrote:
>I know all is right if GCC just overwrites the page->flags with data
>that keeps PG_locked set. But GCC doesn't guarantee that. GCC can as
>well do:
> flags = page->flags;
> page->flags = 0;
> change flags here
> page->flags = flags


>From a C language lawyer standpoing a C compiler can do pretty much
whatever it damn well chooses to do, including temporarily changing
"page->flags" even if the C source doesn't have any reference to
"page->flags" at _all_. The compiler might decide that it temporarily
wants to use that memory for something else, and since "Strictly
conforming ANSI C" does not have a notion of threads etc interesting
issues, you can probably argue that just about _anything_ falls under
"gcc doesn't guarantee that".

>probably gcc doesn't, but that's still a kernel bug.

No. It would be a _gcc_ bug if gcc did things to "page->flags" that the
code did not ask it to do. And that is _regardless_ of any notions of
"strictly conforming C code". The fact is, that if gcc were to clear a
bit that the code never clears, that is a HUGE AND GAPING GCC BUG.

Not kernel bug.

The fact is, if we write code that leaves a certain bit unmodified, gcc
MUST NOT modify that bit. If gcc generated code that temporarily
modifies the bit, I can show user-level code that would break with
signals. See "sig_atomic_t" and friends - the compiler simply _has_ to
guarantee that the semantics you write in C code are actually upheld.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.043 / U:6.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site