From: Chris Friesen <cfriesen@nortel.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: akpm@osdl.org, Adrian Bunk <bunk@stusta.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Date: Tue, 29 Mar 2005 08:12:17 -0600 [thread overview]
Message-ID: <42496241.5010509@nortel.com> (raw)
In-Reply-To: <xyDqcv4K.1112093182.7253990.khali@localhost>
Jean Delvare wrote:
> Wow. Great point. I completely missed that possibility. In fact I didn't
> know that the compiler could possibly alter the order of the
> instructions. For one thing, I thought it was simply not allowed to. For
> another, I didn't know that it had been made so aware that it could
> actually figure out how to do this kind of things. What a mess. Let's
> just hope that the gcc folks know their business :)
>
> I'll try to remember this next time I debug something. Do not assume
> that instructions are run in the order seen in the source. Irk.
It gets better, in that the cpus themselves can reorder instructions.
This becomes interesting when dealing with memory being shared between
multiple cpus on SMP machines. Either you need to use existing locking
primitives which enforce ordering or else you need to use explicit
cpu-level ordering instructions to ensure that data gets written/read in
the expected order. (See "mb" and friends in the kernel code.)
Then you get into potential caching issues with memory mapped at
different addresses on cpus with VIVT caches, and that introduces more
issues.
Computers are perfectly predictable, as long as you understand exactly
what you've told them to do...
Chris
next prev parent reply other threads:[~2005-03-29 14:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-27 20:50 [2.6 patch] sound/oss/cs46xx.c: fix a check after use Adrian Bunk
2005-03-27 21:21 ` Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use) Jean Delvare
2005-03-27 21:43 ` Adrian Bunk
2005-03-27 22:34 ` Jean Delvare
2005-03-27 22:45 ` Russell King
2005-03-28 12:54 ` Matthias-Christian Ott
2005-03-28 23:57 ` L. A. Walsh
2005-03-29 6:05 ` Daniel Barkalow
2005-03-29 6:23 ` Andrew Morton
2005-03-29 10:46 ` Jean Delvare
2005-03-29 14:12 ` Chris Friesen [this message]
2005-03-30 1:25 ` Horst von Brand
2005-03-30 7:53 ` Do not misuse Coverity please Jean Delvare
2005-03-30 17:09 ` Horst von Brand
2005-04-11 20:23 ` Pavel Machek
2005-03-30 18:29 ` Shankar Unni
2005-03-30 18:55 ` Olivier Galibert
2005-03-31 2:01 ` Patrick McFarland
2005-03-30 19:14 ` Paulo Marques
2005-03-30 23:11 ` Big GCC bug!!! [Was: Re: Do not misuse Coverity please] Kyle Moffett
2005-03-30 23:38 ` Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please]) Jakub Jelinek
2005-03-31 0:58 ` Kyle Moffett
2005-03-31 1:12 ` Nick Piggin
2005-03-31 1:27 ` Kyle Moffett
2005-03-29 14:22 ` Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use) Daniel Jacobowitz
2005-03-29 22:37 ` Kyle Moffett
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=42496241.5010509@nortel.com \
--to=cfriesen@nortel.com \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).