From: "tip-bot for Ville Syrjälä" <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
bhelgaas@google.com, ville.syrjala@linux.intel.com,
tglx@linutronix.de
Subject: [tip:x86/urgent] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks
Date: Mon, 14 Apr 2014 00:22:42 -0700 [thread overview]
Message-ID: <tip-86e587623a0ca8426267dad8d3eaebd6fc2d00f1@git.kernel.org> (raw)
In-Reply-To: <1397382303-17525-1-git-send-email-ville.syrjala@linux.intel.com>
Commit-ID: 86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Gitweb: http://git.kernel.org/tip/86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
AuthorDate: Sun, 13 Apr 2014 12:45:03 +0300
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 14 Apr 2014 08:50:56 +0200
x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks
Have the KB(),MB(),GB() macros produce unsigned longs to avoid
unintended sign extension issues with the gen2 memory size
detection.
What happens is first the uint8_t returned by
read_pci_config_byte() gets promoted to an int which gets
multiplied by another int from the MB() macro, and finally the
result gets sign extended to size_t.
Although this shouldn't be a problem in practice as all affected
gen2 platforms are 32bit AFAIK, so size_t will be 32 bits.
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1397382303-17525-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/kernel/early-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b0cc380..6e2537c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -240,7 +240,7 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
return base;
}
-#define KB(x) ((x) * 1024)
+#define KB(x) ((x) * 1024UL)
#define MB(x) (KB (KB (x)))
#define GB(x) (MB (KB (x)))
prev parent reply other threads:[~2014-04-14 7:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5348ea4572e7_5d4d7ac86c27677@209.249.196.67.mail>
2014-04-12 13:29 ` Fwd: New Defects reported by Coverity Scan for Linux Bjorn Helgaas
2014-04-12 21:41 ` Ville Syrjälä
2014-04-12 22:41 ` H. Peter Anvin
2014-04-13 9:45 ` [PATCH] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks ville.syrjala
2014-04-14 7:22 ` tip-bot for Ville Syrjälä [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=tip-86e587623a0ca8426267dad8d3eaebd6fc2d00f1@git.kernel.org \
--to=tipbot@zytor.com \
--cc=bhelgaas@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=ville.syrjala@linux.intel.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