From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: [Patch] bte_copy of BTE_MAX_XFER trips BUG_ON -V2
Date: Wed, 04 Feb 2009 16:47:37 +0000 [thread overview]
Message-ID: <20090204164737.GM8577@sgi.com> (raw)
In-Reply-To: <20090204004059.GM8559@sgi.com>
BTE_MAX_XFER is wrong. It is one greater than the number of cache
lines the BTE is actually able to transfer. If you request a transfer
of exactly BTE_MAX_XFER size, you trip a very cryptic BUG_ON() which
should certainly be made more clear.
This patch fixes that constant and also cleans up the BUG_ON()s in
arch/ia64/sn/kernel/bte.c to test one condition per line.
Signed-off-by: Robin Holt <holt@sgi.com>
---
Changes since -V1:
Base the BTE_LEN_MASK upon a 1UL instead of 1 for correctness.
arch/ia64/include/asm/sn/bte.h | 4 ++--
arch/ia64/sn/kernel/bte.c | 7 ++++---
2 files changed, 6 insertions(+), 5 deletions(-)
Index: bte_fixup/arch/ia64/include/asm/sn/bte.h
=================================--- bte_fixup.orig/arch/ia64/include/asm/sn/bte.h 2009-02-04 10:37:29.594750841 -0600
+++ bte_fixup/arch/ia64/include/asm/sn/bte.h 2009-02-04 10:40:32.495791608 -0600
@@ -38,8 +38,8 @@
/* BTE status register only supports 16 bits for length field */
#define BTE_LEN_BITS (16)
-#define BTE_LEN_MASK ((1 << BTE_LEN_BITS) - 1)
-#define BTE_MAX_XFER ((1 << BTE_LEN_BITS) * L1_CACHE_BYTES)
+#define BTE_LEN_MASK ((1UL << BTE_LEN_BITS) - 1)
+#define BTE_MAX_XFER (BTE_LEN_MASK << L1_CACHE_SHIFT)
/* Define hardware */
Index: bte_fixup/arch/ia64/sn/kernel/bte.c
=================================--- bte_fixup.orig/arch/ia64/sn/kernel/bte.c 2009-02-04 10:37:30.026753839 -0600
+++ bte_fixup/arch/ia64/sn/kernel/bte.c 2009-02-04 10:40:11.711701203 -0600
@@ -97,9 +97,10 @@ bte_result_t bte_copy(u64 src, u64 dest,
return BTE_SUCCESS;
}
- BUG_ON((len & L1_CACHE_MASK) ||
- (src & L1_CACHE_MASK) || (dest & L1_CACHE_MASK));
- BUG_ON(!(len < ((BTE_LEN_MASK + 1) << L1_CACHE_SHIFT)));
+ BUG_ON(len & L1_CACHE_MASK);
+ BUG_ON(src & L1_CACHE_MASK);
+ BUG_ON(dest & L1_CACHE_MASK);
+ BUG_ON(len > BTE_MAX_XFER);
/*
* Start with interface corresponding to cpu number
prev parent reply other threads:[~2009-02-04 16:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 0:40 [Patch] bte_copy of BTE_MAX_XFER trips BUG_ON Robin Holt
2009-02-04 16:47 ` Robin Holt [this message]
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=20090204164737.GM8577@sgi.com \
--to=holt@sgi.com \
--cc=linux-ia64@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