2010/2/26 Anton Maksimenkov :
> *result = entry->start + that_random;
ur-r-r-gh *result = entry->end + that_random;
--
antonvm
2010/2/26 Anton Maksimenkov :
>> + ReScan:
It might be better solution. As I said to art@, we might generate
random exactly in uvm_map_findspace().
The idea might be like this. We don't use uvm_map_hint(). In
uvm_map_findspace() we get entry with biggest space. Then we generate
random from range
hi,
looking for anyone who can test attached diff on any 82575 h/w.
this patch includes fixes sent by Atte Peltomaki, that fixed his quadport
card. my main concern is that it removes static recognition of attached
PHY and relies on em_detect_gig_phy(). since such changes have already
caused a
> + int try_rescan = 0;
Oh my mistake, sorry. It was so quick draft...
Of course try_rescan must be not 0 before the first scan:
try_rescan = 1;
> + ReScan:
> tmpsearch.space = length;
> tmp = RB_NFIND(uvm_tree_space, &map->rb_space, &tmpsearch);
> if (tmp == NULL)
2010/2/26 Theo de Raadt :
>> But I just want to add POSSIBILITY to change this. Let sysadmin decide
>> that in some case it NEED "shrink randomness", doesn't matter which
>> bugs _may_ will show themselfs.
> No. We choose to not do that
Ok, I got this. Let it be.
But what about this:
2010/2/26 O
On Fri, Feb 26, 2010 at 12:52:56PM +0500, Anton Maksimenkov wrote:
> 2010/2/26 Otto Moerbeek :
> >> 2.
> ...
> >> I think that we may introduce some variable - sysctl variable or
> >> malloc.conf flag - which will prevent sys_mmap() or uvm_map_hint()
> > If fragmentation really is a problem for yo
> 2010/2/26 Otto Moerbeek :
> >> 2.
> ...
> >> I think that we may introduce some variable - sysctl variable or
> >> malloc.conf flag - which will prevent sys_mmap() or uvm_map_hint()
> > If fragmentation really is a problem for you, my first reaction is:
> > use a machine with a bigger adress spac
