| 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
| ||
|
Date: Wed, 12 Jan 2011 15:27:06 -0800 (PST)
From: Chris Rankin <rankincj@...oo.com>
To: JesseBrandeburg <jesse.brandeburg@...el.com>,
Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>,
Tushar NDave <tushar.n.dave@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jeffrey TKirsher <jeffrey.t.kirsher@...el.com>
Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
Thanks, the problem has not reoccurred since I've rebooted the box with the new e100 module.
However, the problem *did* reoccur when I tried just stopping networking, unloading the old module, loading the new module and restarting networking... (I think there were some residual network packets still taking up memory in the system. Maybe.)
Jan 12 22:27:04 wellhouse kernel: ifconfig: page allocation failure. order:6, mode:0x8020
Jan 12 22:27:04 wellhouse kernel: Pid: 14968, comm: ifconfig Not tainted 2.6.36.3 #1
Jan 12 22:27:04 wellhouse kernel: Call Trace:
Jan 12 22:27:04 wellhouse kernel: [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
Jan 12 22:27:04 wellhouse kernel: [<c106177d>] ? __slab_alloc+0x1eb/0x396
Jan 12 22:27:04 wellhouse kernel: [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
Jan 12 22:27:04 wellhouse kernel: [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
Jan 12 22:27:04 wellhouse kernel: [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
Jan 12 22:27:04 wellhouse kernel: [<c66f67ee>] ? e100_rx_alloc_skb+0x82/0x11d [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f687e>] ? e100_rx_alloc_skb+0x112/0x11d [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f68d7>] ? e100_alloc_cbs+0x4e/0xfa [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f836e>] ? e100_up+0x1b/0xf1 [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f845b>] ? e100_open+0x17/0x3b [e100]
Jan 12 22:27:07 wellhouse kernel: [<c1121630>] ? __dev_open+0x7c/0xa0
Jan 12 22:27:07 wellhouse kernel: [<c11217ed>] ? __dev_change_flags+0x8b/0x100
Jan 12 22:27:07 wellhouse kernel: [<c11218c3>] ? dev_change_flags+0x10/0x3b
Jan 12 22:27:07 wellhouse kernel: [<c1159880>] ? devinet_ioctl+0x25a/0x532
Jan 12 22:27:07 wellhouse kernel: [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
Jan 12 22:27:07 wellhouse kernel: [<c111452a>] ? sock_ioctl+0x0/0x1ca
Jan 12 22:27:07 wellhouse kernel: [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
Jan 12 22:27:07 wellhouse kernel: [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
Jan 12 22:27:07 wellhouse kernel: [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
Jan 12 22:27:07 wellhouse kernel: [<c10636f6>] ? sys_faccessat+0x144/0x151
Jan 12 22:27:07 wellhouse kernel: [<c106e0cc>] ? sys_ioctl+0x2d/0x49
Jan 12 22:27:07 wellhouse kernel: [<c1177dd5>] ? syscall_call+0x7/0xb
Jan 12 22:27:07 wellhouse kernel: Mem-Info:
Jan 12 22:27:07 wellhouse kernel: DMA per-cpu:
Jan 12 22:27:07 wellhouse kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 12 22:27:07 wellhouse kernel: Normal per-cpu:
Jan 12 22:27:07 wellhouse kernel: CPU 0: hi: 6, btch: 1 usd: 1
Jan 12 22:27:07 wellhouse kernel: active_anon:2698 inactive_anon:3626 isolated_anon:0
Jan 12 22:27:07 wellhouse kernel: active_file:2305 inactive_file:3574 isolated_file:0
Jan 12 22:27:07 wellhouse kernel: unevictable:0 dirty:17 writeback:0 unstable:0
Jan 12 22:27:07 wellhouse kernel: free:558 slab_reclaimable:484 slab_unreclaimable:1309
Jan 12 22:27:07 wellhouse kernel: mapped:1209 shmem:650 pagetables:129 bounce:0
Jan 12 22:27:07 wellhouse kernel: DMA free:1044kB min:248kB low:308kB high:372kB active_anon:3516kB inactive_anon:4004kB active_file:1784kB inactive_file:4216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:4kB writeback:0kB mapped:988kB shmem:8kB slab_reclaimable:288kB slab_unreclaimable:188kB kernel_stack:56kB pagetables:76kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 47 47
Jan 12 22:27:07 wellhouse kernel: Normal free:1188kB min:764kB low:952kB high:1144kB active_anon:7276kB inactive_anon:10500kB active_file:7436kB inactive_file:10080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:64kB writeback:0kB mapped:3848kB shmem:2592kB slab_reclaimable:1648kB slab_unreclaimable:5048kB kernel_stack:240kB pagetables:440kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 0 0
Jan 12 22:27:07 wellhouse kernel: DMA: 87*4kB 9*8kB 5*16kB 3*32kB 1*64kB 3*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1044kB
Jan 12 22:27:07 wellhouse kernel: Normal: 123*4kB 11*8kB 0*16kB 1*32kB 1*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1188kB
Jan 12 22:27:07 wellhouse kernel: 6766 total pagecache pages
Jan 12 22:27:07 wellhouse kernel: 237 pages in swap cache
Jan 12 22:27:07 wellhouse kernel: Swap cache stats: add 1830, delete 1593, find 1018/1086
Jan 12 22:27:07 wellhouse kernel: Free swap = 2176336kB
Jan 12 22:27:07 wellhouse kernel: Total swap = 2179596kB
Jan 12 22:27:07 wellhouse kernel: 16383 pages RAM
Jan 12 22:27:07 wellhouse kernel: 826 pages reserved
Jan 12 22:27:07 wellhouse kernel: 5098 pages shared
Jan 12 22:27:07 wellhouse kernel: 12619 pages non-shared
I also noticed that the e100 is still using GFP_ATOMIC in one place. Does this mean that the problem is ultimately only truly fixable by freeing up some memory?
Cheers,
Chris
--- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@...il.com> wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
> To: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
> Cc: "David Miller" <davem@...emloft.net>, "Chris Rankin" <rankincj@...oo.com>, "e1000-devel@...ts.sourceforge.net" <e1000-devel@...ts.sourceforge.net>, "Dave, Tushar N" <tushar.n.dave@...el.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
> Date: Wednesday, 12 January, 2011, 18:14
> Le mercredi 12 janvier 2011 à 10:05
> -0800, Brandeburg, Jesse a écrit :
>
> > First, I don't think the following comment should hold
> up this patch.
> >
> > As a policy question when I asked about using
> __GFP_NOWARN before in other
> > Intel ethernet drivers the consensus seemed to be that
> the warning
> > messages were useful. All our drivers correctly
> handle runtime memory
> > failures, but none of them are currently using
> __GFP_NOWARN.
> >
> > Can I submit patches to change our other drivers to
> __GFP_NOWARN? I think
> > it will make for quite a few less reports of
> non-issues to the list. All
> > our drivers that I would be patching already have
> ethtool counters that
> > count failed allocations.
> >
>
> If an allocation failure is really handled, in the sense
> NIC doesnt
> freeze but only lose one incoming frame, then probably
> yes.
>
> I think the warning message can be useful when driver is
> known to let
> things in a non working state ;)
>
> As you said, this can be done later, here is a respin
> without this bit.
>
> Thanks !
>
> [PATCH v2] e100: use GFP_KERNEL allocations at device init
> stage
>
> In lowmem conditions, e100 driver can fail its
> initialization, because
> of GFP_ATOMIC abuse.
>
> Switch to GFP_KERNEL were applicable.
>
> Reported-by: Chris Rankin <rankincj@...oo.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> ---
> drivers/net/e100.c | 22
> +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index b0aa9e6..c9a2126 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1880,9 +1880,21 @@ static inline void
> e100_start_receiver(struct nic *nic, struct rx *rx)
> }
>
> #define RFD_BUF_LEN (sizeof(struct rfd) +
> VLAN_ETH_FRAME_LEN)
> -static int e100_rx_alloc_skb(struct nic *nic, struct rx
> *rx)
> +
> +static struct sk_buff *e100_alloc_skb(struct net_device
> *dev, gfp_t flags)
> +{
> + struct sk_buff *skb;
> +
> + skb = __netdev_alloc_skb(dev,
> RFD_BUF_LEN + NET_IP_ALIGN, flags);
> + if (NET_IP_ALIGN && skb)
> + skb_reserve(skb,
> NET_IP_ALIGN);
> + return skb;
> +}
> +
> +static int e100_rx_alloc_skb(struct nic *nic, struct rx
> *rx, gfp_t flags)
> {
> - if (!(rx->skb =
> netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
> + rx->skb =
> e100_alloc_skb(nic->netdev, flags);
> + if (!rx->skb)
> return -ENOMEM;
>
> /* Init, and map the RFD. */
> @@ -2026,7 +2038,7 @@ static void e100_rx_clean(struct nic
> *nic, unsigned int *work_done,
>
> /* Alloc new skbs to refill list */
> for (rx = nic->rx_to_use;
> !rx->skb; rx = nic->rx_to_use = rx->next) {
> - if
> (unlikely(e100_rx_alloc_skb(nic, rx)))
> + if
> (unlikely(e100_rx_alloc_skb(nic, rx, GFP_ATOMIC)))
>
> break; /* Better luck next time (see watchdog) */
> }
>
> @@ -2102,13 +2114,13 @@ static int
> e100_rx_alloc_list(struct nic *nic)
> nic->rx_to_use = nic->rx_to_clean
> = NULL;
> nic->ru_running = RU_UNINITIALIZED;
>
> - if (!(nic->rxs = kcalloc(count,
> sizeof(struct rx), GFP_ATOMIC)))
> + if (!(nic->rxs = kcalloc(count,
> sizeof(struct rx), GFP_KERNEL)))
> return -ENOMEM;
>
> for (rx = nic->rxs, i = 0; i <
> count; rx++, i++) {
> rx->next = (i + 1
> < count) ? rx + 1 : nic->rxs;
> rx->prev = (i ==
> 0) ? nic->rxs + count - 1 : rx - 1;
> - if
> (e100_rx_alloc_skb(nic, rx)) {
> + if
> (e100_rx_alloc_skb(nic, rx, GFP_KERNEL)) {
>
> e100_rx_clean_list(nic);
>
> return -ENOMEM;
> }
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists