Re: VM-related Oops: 2.4.15pre1

[torvalds@transmeta.com (Linus Torvalds)]

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