public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: VM-related Oops: 2.4.15pre1
Date: Sun, 18 Nov 2001 08:51:52 +0100	[thread overview]
Message-ID: <20011118085152.D25232@athlon.random> (raw)
In-Reply-To: <20011118051023.A25232@athlon.random> <Pine.LNX.4.33.0111172220300.1290-100000@penguin.transmeta.com> <20011118073730.C25232@athlon.random> <200111180731.fAI7VFa01371@penguin.transmeta.com>
In-Reply-To: <200111180731.fAI7VFa01371@penguin.transmeta.com>; from torvalds@transmeta.com on Sat, Nov 17, 2001 at 11:31:15PM -0800

On Sat, Nov 17, 2001 at 11:31:15PM -0800, Linus Torvalds wrote:
> 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.

I see what you mean of course (the usual problem is that we never know
if gcc could make such decision for whatever subtle optimization, asm
optimizations are all but intuitional). But I just giveup also about the
other thing of reading from C variables that can change under us. So I'm ok
assuming gcc does what we expect here too, even if I'd prefer not to.

> 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.

There should be proper macros to handle those userspace sig_atomic_t
because of that. Anyways I certainly believe there is code playing with
those types from C by hand :).

Andrea

  parent reply	other threads:[~2001-11-18  8:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-16 22:23 VM-related Oops: 2.4.15pre1 Simon Kirby
2001-11-17 22:53 ` Christian Ehrhardt
2001-11-18  3:12 ` Linus Torvalds
2001-11-18  4:10   ` Andrea Arcangeli
2001-11-18  6:24     ` Linus Torvalds
2001-11-18  6:37       ` Andrea Arcangeli
2001-11-18  7:31         ` Linus Torvalds
2001-11-18 12:05           ` Alan Cox
2001-11-19  2:02             ` Linus Torvalds
2001-11-19  2:27               ` Linus Torvalds
2001-11-19 18:40                 ` kuznet
2001-11-19 10:15               ` Alan Cox
2001-11-19 16:39                 ` Linus Torvalds
2001-11-19 18:03                   ` Eric W. Biederman
2001-11-19 19:04                     ` Linus Torvalds
2001-11-19 23:52                   ` John Alvord
2001-11-21  2:31               ` Pavel Machek
     [not found]         ` <200111180731.fAI7VFa01371@penguin.transmeta.com>
2001-11-18  7:51           ` Andrea Arcangeli [this message]
2001-11-18 17:10       ` Horst von Brand
2001-11-19  2:04         ` Linus Torvalds
2001-11-19  3:22           ` Jeff V. Merkey
2001-11-19  8:44           ` David Woodhouse
2001-11-19 16:57             ` Linus Torvalds
2001-11-19 17:56               ` Simon Kirby
2001-11-19 18:03                 ` Linus Torvalds
2001-11-19 18:31                   ` Simon Kirby
2001-11-19 20:01                   ` Marcelo Tosatti
2001-11-19 21:26                     ` Linus Torvalds
2001-11-19 21:49                       ` Rik van Riel
2001-11-19 22:40                         ` Linus Torvalds
2001-11-19 22:59                           ` Rik van Riel
2001-11-19 23:03                             ` Linus Torvalds
2001-11-20  0:06                               ` Rik van Riel
2001-11-20  0:08                                 ` Linus Torvalds
2001-11-20  0:27                                   ` Rik van Riel
2001-11-19 23:27                   ` Simon Kirby
2001-11-19 23:38                     ` Linus Torvalds
2001-11-19 23:52                       ` Simon Kirby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011118085152.D25232@athlon.random \
    --to=andrea@suse.de \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox