Steven Chamberlain wrote:
> Hi,
>
> (I have a Netra X1 also affected by this bug).
>
> Stuart Henderson wrote:
> > could it be this?
> >
> > CVSROOT: /cvs
> > Module name: src
> > Changes by: [email protected] 2014/09/03 18:36:00
> >
> > Modified files:
> > sys/sys : pool.h
> > sys/kern : subr_pool.c
> >
> > Log message:
> > rework how pools with large pages (>PAGE_SIZE) are implemented.
> >
> > this moves the size of the pool page (not arch page) out of the
> > pool allocator into struct pool. this lets us create only two pools
> > for the automatically determined large page allocations instead of
> > 256 of them.
> >
> > while here support using slack space in large pages for the
> > pool_item_header by requiring km_alloc provide pool page aligned
> > memory.
> >
> > lastly, instead of doing incorrect math to figure how how many arch
> > pages to use for large pool pages, just use powers of two.
> >
> > ok mikeb@
>
> This is a really, really long shot, but could the calculation here on
> (unsigned int) pgsize underflow and return true when it shouldn't??
>
> + * Decide whether to put the page header off page to avoid
> + * wasting too large a part of the page. Off-page page headers
> + * go into an RB tree, so we can match a returned item with
> + * its header based on the page address.
> + */
> + if (pgsize - (size * items) > sizeof(struct pool_item_header)) {
> + flags |= PR_PHINPAGE;
> + off = pgsize - sizeof(struct pool_item_header);
That's interesting. I agree that test could perhaps be improved by writing it
if (pgsize > size * items + sizeof(struct pool_item_header))
