In article <20011118073730.C25232@athlon.random>,
Andrea Arcangeli <andrea@suse.de> 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
Sure.
>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.
Linus
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:17 EST