Date: Mon, 28 Jun 2004 20:44:46 -0400 From: Brian Fundakowski Feldman <green@FreeBSD.org> To: ticso@cicely.de Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c Message-ID: <20040629004446.GA25180@green.homeunix.org> In-Reply-To: <20040629000643.GK1787@cicely12.cicely.de> References: <200406281915.i5SJFeaV060231@repoman.freebsd.org> <20040628224321.GJ1787@cicely12.cicely.de> <16608.44441.720450.793280@grasshopper.cs.duke.edu> <20040629000643.GK1787@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 29, 2004 at 02:06:44AM +0200, Bernd Walter wrote:
> On Mon, Jun 28, 2004 at 07:45:29PM -0400, Andrew Gallatin wrote:
> >
> > Bernd Walter writes:
> > > On Mon, Jun 28, 2004 at 07:15:40PM +0000, Andrew Gallatin wrote:
> > > > gallatin 2004-06-28 19:15:40 UTC
> > > >
> > > > FreeBSD src repository
> > > >
> > > > Modified files:
> > > > sys/vm vm_map.c
> > > > Log:
> > > > Fix alpha - the use of min() on longs was loosing the high bits and
> > > > returning wrong answers, leading to strange values vm2->vm_{s,t,d}size.
> > >
> > > Thanks.
> > >
> > > Would this also explain why setting (MAX|DFL)DSIZ to n*4G never worked?
> > >
> >
> > I don't think so, this was brand-new code.
>
> Ah - OK.
>
> > What's the symptom of MAXDSIZ > 4GB not working? I think the amd64
> > people have fixed a lot of bugs in this area on the last few months.
>
> The symptoms were exactly the same as in this case.
> It wasn't >4G not working, but n * 4G failed - e.g. 5G was fine.
> However - I never tested if the 5G could really be used.
> Looked very much like a 31 or 32 bit truncation somewere.
>
> > Have you tried it recently?
>
> No - Never tried those values again - just remembered my last tests a
> long time ago.
You can try compiling with this patch and the GCC flag -Wwidth-truncation.
Unfortunately, there are many places where the GCC type checker apparently
can't access enough information as to determine that the maximal and
minimal values for an expression fit the constraints of the type it's
being passed as.
For example, the following code will give you a warning:
newend = min(entry->end,
(vm_offset_t)vm1->vm_daddr + ctob(vm1->vm_dsize));
vm2->vm_dsize += btoc(newend - entry->start);
However, this does, too:
pmap_protect(map->pmap, current->start,
current->end,
current->protection & MASK(current));
The value current->protection provides the minimal and maximal
bounds -- it's the same type as the function expects -- but since
it's not a constant there's no apparent way for phases before
code generation to determine that.
Still, I bet you will be able to find bugs with this flag, especially
on a 64-bit platform, but you'll have to wade through warnings which
are probably incorrect.
<URL:http://green.homeunix.org/~green/gcc-Wwidth_truncation.patch>;
--
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green@FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040629004446.GA25180>