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