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-next>] [day] [month] [year] [list]
Message-Id: <20090413124228.be31e9f3.akpm@linux-foundation.org>
Date:	Mon, 13 Apr 2009 12:42:28 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	reeve.yang@...il.com
Cc:	bugzilla-daemon@...zilla.kernel.org, netdev@...r.kernel.org,
	jeffrey.t.kirsher@...el.com, jesse.brandeburg@...el.com,
	bruce.w.allan@...el.com, peter.p.waskiewicz.jr@...el.com,
	john.ronciak@...el.com
Subject: Re: [Bugme-new] [Bug 13084] New: page allocation failure. order:0,
 mode:0x20


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 13 Apr 2009 19:27:27 GMT
bugzilla-daemon@...zilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=13084
> 
>            Summary: page allocation failure. order:0, mode:0x20
>            Product: Memory Management
>            Version: 2.5
>     Kernel Version: 2.6.17.4
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: Page Allocator
>         AssignedTo: akpm@...ux-foundation.org
>         ReportedBy: reeve.yang@...il.com
>         Regression: No
> 
> 
> Created an attachment (id=20964)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=20964)
> kernel config file.
> 
> The system is Intel Xeon Quad core with 8G physical RAM. When it's under UPD
> loads, e.g., DNS queries, the box is stuck in terms it cannot be pinged or
> login. By checking syslog, I'm seeing following trace back from various
> dameon/processes. The network controller is E1000 82571 with NAPI enabled in
> kernel.
>
> page allocation failure. order:0, mode:0x20

This is very common.  e1000 attempts to do large memory allocations
from within interrupt context and the page allocator cannot satisfy the
allocation and is not allowed to do the necessary work to make the
allocation attempt succeed.  It's the same with all net drivers, but
e1000 is especially prone, apparently because of hardware suckiness.

However the networking stack should just drop the packet and the system
will recover.

You report is unclear.  Yes, the machine wedges up under the UDP load. 
But does it recover when the other machine stops spraying UDP packets
at this machine?  It _should_ recover.  If it does not, we have a bug
somewhere.

The usual workaround for these problems is to increase the value in
/proc/sys/vm/min_free_kbytes.

2.6.17 is fairly old.  If we need to do additional work on this report
then we'll be asking you to test something more recent - ideally
2.6.29.

Thanks.

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ