----- [email protected] 写道：
> On Mon, May 28, 2012 at 5:29 AM, Zhenzhong Duan
> <[email protected]> wrote:
> > When boot x86_64 kernel on sun G5+ with 4T mem, see an overflow in
> mtrr cleanup as below.
> >
> > *BAD*gran_size: 2G chunk_size: 2G num_reg: 10 lose cover
> RAM:
> > -18014398505283592M
> >
> > This is because 1<<31 sign extended.
> > Use explicit type conversion to force a 64bit constant to fix it.
> > Useful for mem larger than or equal to 4T.
> >
> > Signed-off-by: Zhenzhong Duan <[email protected]>
> > ---
> > arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
> b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > index ac140c7..853a4c6 100644
> > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> > @@ -266,7 +266,7 @@ range_to_mtrr(unsigned int reg, unsigned long
> range_startk,
> > if (align > max_align)
> > align = max_align;
> >
> > - sizek = 1 << align;
> > + sizek = (unsigned long)1 << align;
>
> how about
>
> sizek = 1UL << align;
>
>
> > if (debug_print) {
> > char start_factor = 'K', size_factor = 'K';
> > unsigned long start_base, size_base;
> > --
> > 1.7.3
> >
Yes, this looks more clean although same compiling result. Should i resend it?