Re: [PATCH 1/2] net: Export __netdev_alloc_frag() to allow gfp_mask flags

[Eric Dumazet]

On Wed, 2015-07-29 at 16:22 -0400, Murali Karicheri wrote:
> Eric,
> 
> On 07/29/2015 12:31 PM, Eric Dumazet wrote:
> > On Wed, 2015-07-29 at 11:10 -0400, WingMan Kwok wrote:
> >> This patch makes the function __netdev_alloc_frag() non-static and
> >> exports it so that drivers that need to specify additional flags,
> >> such as __GFP_DMA, can use it. The currently exported function,
> >> netdev_alloc_frag() doesn't allow passing in gfp_mask flags.
> >>
> >> Signed-off-by: WingMan Kwok <w-kwok2@xxxxxx>
> >> Signed-off-by: Reece R. Pollack <x0183204@xxxxxx>
> >> ---
> >>   include/linux/skbuff.h |    1 +
> >>   net/core/skbuff.c      |    3 ++-
> >>   2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > You can not do this.
> >
> > __napi_alloc_frag() uses __alloc_page_frag() using a per cpu reserve.
> >
> Thanks for your response.
> 
> I assume you mean to say __netdev_alloc_frag() which is what the patch 
> affects. Right?
> 
> > This per cpu reserve would be shared by regular GFP_ATOMIC and your
> > __GFP_DMA allocations.
> 
> I am trying to understand the issue here. Is there any issue in sharing 
> this per CPU reserve between DMA and ATOMIC allocations. Without this 
> flag, the assumption is this function can return memory which is not 
> DMA-able and this flag assures it is allocated from DMA zone.

First caller __netdev_alloc_frag() uses GFP_ATOMIC.

A big page (32 KB) is allocated and stored into cache. Part of it given
to caller. (like 1536 bytes or so)

Then your driver calls with __GFP_DMA.

We find a prior page on percpu cache with enough room in it to allocate
a fragment.

Your driver getd a fragment from the prior GFP_ATOMIC allocation, with
no DMA guarantee.

Therefore, your patch is not working in all cases.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/