On Fri, Jun 21, 2019 at 5:12 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Fri 21-06-19 16:10:19, Alexander Potapenko wrote: > > On Fri, Jun 21, 2019 at 10:57 AM Alexander Potapenko <glider@xxxxxxxxxx> wrote: > [...] > > > > > diff --git a/mm/dmapool.c b/mm/dmapool.c > > > > > index 8c94c89a6f7e..e164012d3491 100644 > > > > > --- a/mm/dmapool.c > > > > > +++ b/mm/dmapool.c > > > > > @@ -378,7 +378,7 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags, > > > > > #endif > > > > > spin_unlock_irqrestore(&pool->lock, flags); > > > > > > > > > > - if (mem_flags & __GFP_ZERO) > > > > > + if (want_init_on_alloc(mem_flags)) > > > > > memset(retval, 0, pool->size); > > > > > > > > > > return retval; > > > > > > > > Don't you miss dma_pool_free and want_init_on_free? > > > Agreed. > > > I'll fix this and add tests for DMA pools as well. > > This doesn't seem to be easy though. One needs a real DMA-capable > > device to allocate using DMA pools. > > On the other hand, what happens to a DMA pool when it's destroyed, > > isn't it wiped by pagealloc? > > Yes it should be returned to the page allocator AFAIR. But it is when we > are returning an object to the pool when you want to wipe the data, no? My concern was that dma allocation is something orthogonal to heap and page allocator. I also don't know how many other allocators are left overboard, e.g. we don't do anything to lib/genalloc.c yet. > Why cannot you do it along the already existing poisoning? I can sure keep these bits. Any idea how the correct behavior of dma_pool_alloc/free can be tested? > -- > Michal Hocko > SUSE Labs -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
