public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: discuss@x86-64.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
	jbeulich@novell.com
Subject: Re: [PATCH] [3/4] i386: Fix overflow in e820_all_mapped
Date: Fri, 28 Apr 2006 08:08:15 +0200	[thread overview]
Message-ID: <200604280808.16256.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0604272237430.3701@g5.osdl.org>

On Friday 28 April 2006 07:39, Linus Torvalds wrote:
> 
> On Fri, 28 Apr 2006, Andi Kleen wrote:
> > 
> > The 32bit version of e820_all_mapped() needs to use u64 to avoid
> > overflows on PAE systems.  Pointed out by Jan Beulich
> 
> I don't think that's true.
> 
> It can't be called with 64-bit arguments anyway. If the base address 
> doesn't fit in 32-bit, we'd be screwed in other places, afaik.

To quote Jan's original description (should have put that in)
I think it's needed.

-Andi

>>>

>> It would seem to me that using 'unsigned long' for start and end is inappropriate on 32bits; at least start should
be
>> 'unsigned long long' as it gets updated from ei->addr + ei->size, which may (truncated to 32 bits) happen to be
zero.
>
>the current user has it 32 bit for sure; once another user appears we certainly can fix this...

The effect is not on the current user's parameter passing, but in the result the function may produce. If, say, for the
PCI mmconfig and BIOS space, there is a (reserved) entry starting at E0000000 and being 20000000 in size, then as far as
I can tell the function will return zero (rather than one).

<<<

  reply	other threads:[~2006-04-28  6:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-28  5:28 [PATCH] [3/4] i386: Fix overflow in e820_all_mapped Andi Kleen
2006-04-28  5:39 ` Linus Torvalds
2006-04-28  6:08   ` Andi Kleen [this message]
2006-04-28 14:52     ` Linus Torvalds
2006-04-28  7:07   ` [discuss] " Jan Beulich
2006-04-28  7:34     ` Arjan van de Ven

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=200604280808.16256.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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