Re: [PATCH 2/3] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory

[Hans de Goede]

Hi,

On 29-03-18 18:39, Greg Kroah-Hartman wrote:
> On Thu, Mar 29, 2018 at 03:42:59PM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 29-03-18 13:58, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 29, 2018 at 01:21:15PM +0200, Hans de Goede wrote:
> > > > It is not possible to get DMA32 zone memory through kmalloc,
> > >
> > > Why can't we just fix that issue here instead?
> >
> > AFAIK that would go against the design of the whole slab
> > allocator, it creates buckets (kmem_cache objects) for
> > differently sized allocs out of the normal memzone,
> > you cannot select what memzone you want with kmalloc,
> > if you need to specify a memzone you need to use either
> > dma specific malloc functions such as the dmapool.h
> > functions, or directly call alloc_pages / get_free_pages.
> >
> > A quick grep on the drivers dir shows 50 files using
> > GFP_DMA32 and almost all are passing it to alloc_page
> > or __get_page.
>
> If there are 50 users of such an api, why is the mm core not handling
> this for drivers automatically?  It seems harsh that they all have to do
> this type of allocation on their own.

True, but fixing that falls outside the scope of this patch-set,
which is purely a small bug-fix patchset fixing a bug which
is being hit be users in the field atm.

So it would be nice if we can get (version 2) of this patch-set
merged.

> > I do actually see 2 drivers which are passing it to
> > kmalloc, which as said will not work I will mail the
> > maintainers of those about this.
>
> If they haven't noticed that their hardware isn't working, perhaps they
> don't need to set that flag?  :)

Or they have never tested with more then 4G of RAM, which is what
caused me to not find this problem in my own testing of the
vboxguest driver.

Regards,

Hans