linux-kernel - Re: [PATCH 1/2] net: Export __netdev_alloc_frag() to allow gfp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1438202275.20182.99.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 29 Jul 2015 22:37:55 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Murali Karicheri <m-karicheri2@...com>
Cc:	WingMan Kwok <w-kwok2@...com>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] net: Export __netdev_alloc_frag() to allow gfp_mask
 flags

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@...com>
> >> Signed-off-by: Reece R. Pollack <x0183204@...com>
> >> ---
> >>   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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/