[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <617E1C2C70743745A92448908E030B2A0224C88B@scsmsx411.amr.corp.intel.com>
Date: Fri, 10 Aug 2007 15:33:27 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: "Andreas Schwab" <schwab@...e.de>
Cc: "Chris Snook" <csnook@...hat.com>, <linux-kernel@...r.kernel.org>,
<linux-arch@...r.kernel.org>, <torvalds@...ux-foundation.org>,
<netdev@...r.kernel.org>, <akpm@...ux-foundation.org>,
<ak@...e.de>, <heiko.carstens@...ibm.com>, <davem@...emloft.net>,
<schwidefsky@...ibm.com>, <wensong@...ux-vs.org>,
<horms@...ge.net.au>, <wjiang@...ilience.com>,
<cfriesen@...tel.com>, <zlynx@....org>, <rpjday@...dspring.com>,
<jesper.juhl@...il.com>
Subject: RE: [PATCH 9/24] make atomic_read() behave consistently on ia64
> 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().
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.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists