[PATCH] net: suppress warnings on dev_alloc_skb

[PATCH] net: suppress warnings on dev_alloc_skb

[Neil Horman]

Noticed an allocation failure in a network driver the other day on a 32 bit
system:

DMA-API: debugging out of memory - disabling
bnx2fc: adapter_lookup: hba NULL
lldpad: page allocation failure. order:0, mode:0x4120
Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
Call Trace:
 [<c08a4086>] ? printk+0x19/0x23
 [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
 [<c0649d02>] ? free_object+0x82/0xa0
 [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
 [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
 [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
 [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
 [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
 [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
 [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
 [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
 [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
...

Thought that perhaps the big splat in the logs wasn't really necessecary, as
all call sites for dev_alloc_skb:

a) check the return code for the function

and

b) either print their own error message or have a recovery path that makes the
warning moot.

So, I added __GFP_NOWARN to the gfp_flags, to be added unless DEBUG was enabled,
in which case getting the splat makes a bit more sense

applies to the net tree

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
---
 include/linux/skbuff.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 15d0df9..8e61fe7 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2452,6 +2452,10 @@ static inline struct page *__dev_alloc_pages(gfp_t gfp_mask,
 	 */
 	gfp_mask |= __GFP_COLD | __GFP_COMP | __GFP_MEMALLOC;
 
+#ifndef DEBUG
+	gfp_mask |= __GFP_NOWARN;
+#endif
+
 	return alloc_pages_node(NUMA_NO_NODE, gfp_mask, order);
 }
 
-- 
2.5.5

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Eric Dumazet]

On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
> Noticed an allocation failure in a network driver the other day on a 32 bit
> system:
> 
> DMA-API: debugging out of memory - disabling
> bnx2fc: adapter_lookup: hba NULL
> lldpad: page allocation failure. order:0, mode:0x4120
> Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
> Call Trace:
>  [<c08a4086>] ? printk+0x19/0x23
>  [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
>  [<c0649d02>] ? free_object+0x82/0xa0
>  [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
>  [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
>  [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
>  [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
>  [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
>  [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
>  [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
>  [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
>  [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
> ...


Well, maybe this call site (via ixgbe_configure_rx_ring()) should be
using GFP_KERNEL instead of GFP_ATOMIC.

Otherwise, if you are unlucky, not a single page would be allocated and
RX ring buffer would be empty.

So the 'fix' could be limited to GFP_ATOMIC callers ?

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c413c588a24f854be9e4df78d8a6872b6b1ff9f3..61b923f1520845145a5470d752b278d283cbb348 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2467,7 +2467,7 @@ static inline struct page *__dev_alloc_pages(gfp_t gfp_mask,
 
 static inline struct page *dev_alloc_pages(unsigned int order)
 {
-	return __dev_alloc_pages(GFP_ATOMIC, order);
+	return __dev_alloc_pages(GFP_ATOMIC | __GFP_NOWARN, order);
 }
 
 /**
@@ -2485,7 +2485,7 @@ static inline struct page *__dev_alloc_page(gfp_t gfp_mask)
 
 static inline struct page *dev_alloc_page(void)
 {
-	return __dev_alloc_page(GFP_ATOMIC);
+	return dev_alloc_pages(0);
 }
 
 /**

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Alexander Duyck]

On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
>> Noticed an allocation failure in a network driver the other day on a 32 bit
>> system:
>>
>> DMA-API: debugging out of memory - disabling
>> bnx2fc: adapter_lookup: hba NULL
>> lldpad: page allocation failure. order:0, mode:0x4120
>> Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
>> Call Trace:
>>  [<c08a4086>] ? printk+0x19/0x23
>>  [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
>>  [<c0649d02>] ? free_object+0x82/0xa0
>>  [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
>>  [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
>>  [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
>>  [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
>>  [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
>>  [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
>>  [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
>>  [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
>>  [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
>> ...
>
>
> Well, maybe this call site (via ixgbe_configure_rx_ring()) should be
> using GFP_KERNEL instead of GFP_ATOMIC.

The problem is the ixgbe driver is using the same function for
allocating memory in the softirq and in the init.  As such it has to
default to GFP_ATOMIC so that it doesn't screw up the NAPI allocation
case.

> Otherwise, if you are unlucky, not a single page would be allocated and
> RX ring buffer would be empty.
>
> So the 'fix' could be limited to GFP_ATOMIC callers ?
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index c413c588a24f854be9e4df78d8a6872b6b1ff9f3..61b923f1520845145a5470d752b278d283cbb348 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2467,7 +2467,7 @@ static inline struct page *__dev_alloc_pages(gfp_t gfp_mask,
>
>  static inline struct page *dev_alloc_pages(unsigned int order)
>  {
> -       return __dev_alloc_pages(GFP_ATOMIC, order);
> +       return __dev_alloc_pages(GFP_ATOMIC | __GFP_NOWARN, order);
>  }
>
>  /**
> @@ -2485,7 +2485,7 @@ static inline struct page *__dev_alloc_page(gfp_t gfp_mask)
>
>  static inline struct page *dev_alloc_page(void)
>  {
> -       return __dev_alloc_page(GFP_ATOMIC);
> +       return dev_alloc_pages(0);
>  }
>
>  /**
>
>

I agree.  This is likely a much better way to go.

- Alex

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Neil Horman]

On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
> >> Noticed an allocation failure in a network driver the other day on a 32 bit
> >> system:
> >>
> >> DMA-API: debugging out of memory - disabling
> >> bnx2fc: adapter_lookup: hba NULL
> >> lldpad: page allocation failure. order:0, mode:0x4120
> >> Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
> >> Call Trace:
> >>  [<c08a4086>] ? printk+0x19/0x23
> >>  [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
> >>  [<c0649d02>] ? free_object+0x82/0xa0
> >>  [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
> >>  [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
> >>  [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
> >>  [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
> >>  [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
> >>  [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
> >>  [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
> >>  [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
> >>  [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
> >> ...
> >
> >
> > Well, maybe this call site (via ixgbe_configure_rx_ring()) should be
> > using GFP_KERNEL instead of GFP_ATOMIC.
> 
> The problem is the ixgbe driver is using the same function for
> allocating memory in the softirq and in the init.  As such it has to
> default to GFP_ATOMIC so that it doesn't screw up the NAPI allocation
> case.
> 

I suppose a happy medium would be to extend dev_alloc_pages to accept a gfp
argument, and then have the function itself only set __GFP_NOWARN, if ATOMIC is
also set?

Neil

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Alexander Duyck]

On Wed, May 18, 2016 at 12:29 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
>> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
>> >> Noticed an allocation failure in a network driver the other day on a 32 bit
>> >> system:
>> >>
>> >> DMA-API: debugging out of memory - disabling
>> >> bnx2fc: adapter_lookup: hba NULL
>> >> lldpad: page allocation failure. order:0, mode:0x4120
>> >> Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
>> >> Call Trace:
>> >>  [<c08a4086>] ? printk+0x19/0x23
>> >>  [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
>> >>  [<c0649d02>] ? free_object+0x82/0xa0
>> >>  [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
>> >>  [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
>> >>  [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
>> >>  [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
>> >>  [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
>> >>  [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
>> >>  [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
>> >>  [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
>> >>  [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
>> >> ...
>> >
>> >
>> > Well, maybe this call site (via ixgbe_configure_rx_ring()) should be
>> > using GFP_KERNEL instead of GFP_ATOMIC.
>>
>> The problem is the ixgbe driver is using the same function for
>> allocating memory in the softirq and in the init.  As such it has to
>> default to GFP_ATOMIC so that it doesn't screw up the NAPI allocation
>> case.
>>
>
> I suppose a happy medium would be to extend dev_alloc_pages to accept a gfp
> argument, and then have the function itself only set __GFP_NOWARN, if ATOMIC is
> also set?

Why bother?  I really think Eric's patch is the way to go.

We can already pass gfp flags to __dev_alloc_pages so if we need to
pass flags we can use that.  Otherwise for the users of dev_alloc_page
and dev_alloc_pages we can just pass GFP_ATOMIC | __GFP_NOWARN like
Eric did in his example patch.

- Alex

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Neil Horman]

On Wed, May 18, 2016 at 01:48:15PM -0700, Alexander Duyck wrote:
> On Wed, May 18, 2016 at 12:29 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
> >> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> > On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
> >> >> Noticed an allocation failure in a network driver the other day on a 32 bit
> >> >> system:
> >> >>
> >> >> DMA-API: debugging out of memory - disabling
> >> >> bnx2fc: adapter_lookup: hba NULL
> >> >> lldpad: page allocation failure. order:0, mode:0x4120
> >> >> Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
> >> >> Call Trace:
> >> >>  [<c08a4086>] ? printk+0x19/0x23
> >> >>  [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
> >> >>  [<c0649d02>] ? free_object+0x82/0xa0
> >> >>  [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
> >> >>  [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
> >> >>  [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
> >> >>  [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
> >> >>  [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
> >> >>  [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
> >> >>  [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
> >> >>  [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
> >> >>  [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
> >> >> ...
> >> >
> >> >
> >> > Well, maybe this call site (via ixgbe_configure_rx_ring()) should be
> >> > using GFP_KERNEL instead of GFP_ATOMIC.
> >>
> >> The problem is the ixgbe driver is using the same function for
> >> allocating memory in the softirq and in the init.  As such it has to
> >> default to GFP_ATOMIC so that it doesn't screw up the NAPI allocation
> >> case.
> >>
> >
> > I suppose a happy medium would be to extend dev_alloc_pages to accept a gfp
> > argument, and then have the function itself only set __GFP_NOWARN, if ATOMIC is
> > also set?
> 
> Why bother?  I really think Eric's patch is the way to go.
> 
> We can already pass gfp flags to __dev_alloc_pages so if we need to
> pass flags we can use that.  Otherwise for the users of dev_alloc_page
> and dev_alloc_pages we can just pass GFP_ATOMIC | __GFP_NOWARN like
> Eric did in his example patch.
> 
> - Alex
> 
Oh, my bad, I misread what he was saying.  Yeah, thats the way to go.

Neil

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Eric Dumazet]

On Wed, 2016-05-18 at 17:09 -0400, Neil Horman wrote:

> Oh, my bad, I misread what he was saying.  Yeah, thats the way to go.

Please submit a v2 ;)

Thanks

Re: [PATCH] net: suppress warnings on dev_alloc_skb

[Neil Horman]

On Wed, May 18, 2016 at 02:47:05PM -0700, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 17:09 -0400, Neil Horman wrote:
> 
> > Oh, my bad, I misread what he was saying.  Yeah, thats the way to go.
> 
> Please submit a v2 ;)
> 
> Thanks
> 
Will do shortly :)
Neil

> 
> 
> 

[PATCHv2] net: suppress warnings on dev_alloc_skb

[Neil Horman]

Noticed an allocation failure in a network driver the other day on a 32 bit
system:

DMA-API: debugging out of memory - disabling
bnx2fc: adapter_lookup: hba NULL
lldpad: page allocation failure. order:0, mode:0x4120
Pid: 4556, comm: lldpad Not tainted 2.6.32-639.el6.i686.debug #1
Call Trace:
 [<c08a4086>] ? printk+0x19/0x23
 [<c05166a4>] ? __alloc_pages_nodemask+0x664/0x830
 [<c0649d02>] ? free_object+0x82/0xa0
 [<fb4e2c9b>] ? ixgbe_alloc_rx_buffers+0x10b/0x1d0 [ixgbe]
 [<fb4e2fff>] ? ixgbe_configure_rx_ring+0x29f/0x420 [ixgbe]
 [<fb4e228c>] ? ixgbe_configure_tx_ring+0x15c/0x220 [ixgbe]
 [<fb4e3709>] ? ixgbe_configure+0x589/0xc00 [ixgbe]
 [<fb4e7be7>] ? ixgbe_open+0xa7/0x5c0 [ixgbe]
 [<fb503ce6>] ? ixgbe_init_interrupt_scheme+0x5b6/0x970 [ixgbe]
 [<fb4e8e54>] ? ixgbe_setup_tc+0x1a4/0x260 [ixgbe]
 [<fb505a9f>] ? ixgbe_dcbnl_set_state+0x7f/0x90 [ixgbe]
 [<c088d80d>] ? dcb_doit+0x10ed/0x16d0
...

Thought that perhaps the big splat in the logs wasn't really necessecary, as
all call sites for dev_alloc_skb:

a) check the return code for the function

and

b) either print their own error message or have a recovery path that makes the
warning moot.

Fix it by modifying dev_alloc_pages to pass __GFP_NOWARN as a gfp flag to
suppress the warning

applies to the net tree

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Alexander Duyck <alexander.duyck@gmail.com>

---
Change notes
v2) Modified patch to only apply to dev_alloc_pages, so that callers have the
option to get the warning by using the non-wrapped __dev_alloc_pages as per
suggestion from Eric D.
---
 include/linux/skbuff.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 15d0df9..c93d809 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2457,7 +2457,7 @@ static inline struct page *__dev_alloc_pages(gfp_t gfp_mask,
 
 static inline struct page *dev_alloc_pages(unsigned int order)
 {
-	return __dev_alloc_pages(GFP_ATOMIC, order);
+	return __dev_alloc_pages(GFP_ATOMIC | __GFP_NOWARN, order);
 }
 
 /**
@@ -2475,7 +2475,7 @@ static inline struct page *__dev_alloc_page(gfp_t gfp_mask)
 
 static inline struct page *dev_alloc_page(void)
 {
-	return __dev_alloc_page(GFP_ATOMIC);
+	return dev_alloc_pages(0);
 }
 
 /**
-- 
2.5.5

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[Eric Dumazet]

On Thu, 2016-05-19 at 11:30 -0400, Neil Horman wrote:
> Noticed an allocation failure in a network driver the other day on a 32 bit
> system:

> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Alexander Duyck <alexander.duyck@gmail.com>

Acked-by: Eric Dumazet <edumazet@google.com>

Thanks Neil

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[Eric Dumazet]

On Thu, 2016-05-19 at 11:30 -0400, Neil Horman wrote:
> Noticed an allocation failure in a network driver the other day on a 32 bit
> system:

Presumably driver could fall back to HIGH memory allocation for the page
frag.

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[Neil Horman]

On Thu, May 19, 2016 at 08:48:56AM -0700, Eric Dumazet wrote:
> On Thu, 2016-05-19 at 11:30 -0400, Neil Horman wrote:
> > Noticed an allocation failure in a network driver the other day on a 32 bit
> > system:
> 
> Presumably driver could fall back to HIGH memory allocation for the page
> frag.
> 
Is that safe on a 32 bit system?
Neil

> 
> 
> 

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[Eric Dumazet]

On Thu, 2016-05-19 at 13:34 -0400, Neil Horman wrote:
> On Thu, May 19, 2016 at 08:48:56AM -0700, Eric Dumazet wrote:
> > On Thu, 2016-05-19 at 11:30 -0400, Neil Horman wrote:
> > > Noticed an allocation failure in a network driver the other day on a 32 bit
> > > system:
> > 
> > Presumably driver could fall back to HIGH memory allocation for the page
> > frag.
> > 
> Is that safe on a 32 bit system?
> Neil

This should be.

Unless a bug somewhere was added, since most dev are using 64bit kernels
these days.

All frag consumers use the appropriate kmap_atomic()/kunmap_atomic()
pairs before copying data from a page frag. Meaning the page can be in
HIGH memory.

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[Neil Horman]

On Thu, May 19, 2016 at 10:39:50AM -0700, Eric Dumazet wrote:
> On Thu, 2016-05-19 at 13:34 -0400, Neil Horman wrote:
> > On Thu, May 19, 2016 at 08:48:56AM -0700, Eric Dumazet wrote:
> > > On Thu, 2016-05-19 at 11:30 -0400, Neil Horman wrote:
> > > > Noticed an allocation failure in a network driver the other day on a 32 bit
> > > > system:
> > > 
> > > Presumably driver could fall back to HIGH memory allocation for the page
> > > frag.
> > > 
> > Is that safe on a 32 bit system?
> > Neil
> 
> This should be.
> 
> Unless a bug somewhere was added, since most dev are using 64bit kernels
> these days.
> 
> All frag consumers use the appropriate kmap_atomic()/kunmap_atomic()
> pairs before copying data from a page frag. Meaning the page can be in
> HIGH memory.
> 
Ok, understood, I'll look into a fallback option soon
Neil

> 
> 
> 
> 
> 
> 

Re: [PATCHv2] net: suppress warnings on dev_alloc_skb

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 19 May 2016 11:30:54 -0400

> Noticed an allocation failure in a network driver the other day on a 32 bit
> system:
 ...
> Thought that perhaps the big splat in the logs wasn't really necessecary, as
> all call sites for dev_alloc_skb:
> 
> a) check the return code for the function
> 
> and
> 
> b) either print their own error message or have a recovery path that makes the
> warning moot.
> 
> Fix it by modifying dev_alloc_pages to pass __GFP_NOWARN as a gfp flag to
> suppress the warning
> 
> applies to the net tree
> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

Applied, thanks Neil.