Messages in this thread | | | Subject | Re: [PATCH 2/3] virt: vbox: Use __get_free_pages instead of kmalloc for DMA32 memory | From | Hans de Goede <> | Date | Tue, 3 Apr 2018 15:20:55 +0200 |
| |
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
| |