From: Chris Snook <csnook@redhat.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Andreas Schwab <schwab@suse.de>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
torvalds@linux-foundation.org, netdev@vger.kernel.org,
akpm@linux-foundation.org, ak@suse.de, heiko.carstens@de.ibm.com,
davem@davemloft.net, schwidefsky@de.ibm.com,
wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com,
cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com,
jesper.juhl@gmail.com
Subject: Re: [PATCH 9/24] make atomic_read() behave consistently on ia64
Date: Fri, 10 Aug 2007 18:43:04 -0400 [thread overview]
Message-ID: <46BCE9F8.4060009@redhat.com> (raw)
In-Reply-To: <617E1C2C70743745A92448908E030B2A0224C88B@scsmsx411.amr.corp.intel.com>
Luck, Tony wrote:
>> Use atomic64_read to read an atomic64_t.
>
> Thanks Andreas!
>
> Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
> by your change to atomic_read().
I figured as much. Thanks for confirming this.
> With this applied together with shuffling the volatile from the
> declaration to the usage (in both atomic_read() and atomic_set()
> the generated code *almost* reverts to the original.
>
> There are some differences where ld4 have turned into ld8 though.
> Are these bugs in the use of atomic_add() and atomic_sub(). E.g.
> the first of these changes is in: ipc/msg.c:freeque() where we have:
>
> atomic_sub(msg->q_cbytes, &msg_bytes);
>
> Now the type of msg->q_cbytes is "unsigned long" ... so it seems a
> poor idea to subtract such a large typed object from "msg_bytes"
> which is a mere slip of an atomic_t.
>
> Or is there some other type-wrangling that needs to happen in
> include/asm-ia64/atomic.h? There are a total of nineteen of
> these ld4->ld8 transforms.
Possibly. Either that or we've uncovered some latent bugs. Maybe a
combination of the two. Can you list those 19 changes so we can
evaluate them? I'm told there were some *(volatile *) bugs fixed in gcc
recently, so it's also possible your 3.4.6 is showing those. I can test
that on a more recent gcc on ia64 if it's inconvenient for you to do so
on your test box.
-- Chris
next prev parent reply other threads:[~2007-08-10 22:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 13:51 [PATCH 9/24] make atomic_read() behave consistently on ia64 Chris Snook
2007-08-09 21:03 ` Luck, Tony
2007-08-09 21:03 ` Luck, Tony
2007-08-10 19:51 ` Chris Snook
2007-08-10 21:19 ` Luck, Tony
2007-08-10 21:19 ` Luck, Tony
2007-08-10 21:42 ` Andreas Schwab
2007-08-10 21:42 ` Andreas Schwab
2007-08-10 22:33 ` Luck, Tony
2007-08-10 22:33 ` Luck, Tony
2007-08-10 22:43 ` Chris Snook [this message]
2007-08-10 22:59 ` Luck, Tony
2007-08-10 22:59 ` Luck, Tony
2007-08-10 23:09 ` Linus Torvalds
2007-08-10 23:15 ` Chris Snook
2007-08-11 0:35 ` Paul Mackerras
2007-08-13 6:30 ` Chris Snook
2007-08-13 7:39 ` Geert Uytterhoeven
2007-08-10 23:32 ` Luck, Tony
2007-08-10 23:32 ` Luck, Tony
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=46BCE9F8.4060009@redhat.com \
--to=csnook@redhat.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=horms@verge.net.au \
--cc=jesper.juhl@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rpjday@mindspring.com \
--cc=schwab@suse.de \
--cc=schwidefsky@de.ibm.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=wensong@linux-vs.org \
--cc=wjiang@resilience.com \
--cc=zlynx@acm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.