From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 14 May 2007 15:48:37 +1000
Hi Dave:
I just got this when rekeying my VPN (2.6.21.1):
events/0: page allocation failure. order:7, mode:0xd0
[c0146235] __alloc_pages+0x1e5/0x2e0
[c0146356] __get_free_pages+0x26/0x50
[c02a01ef]
On Sun, May 13, 2007 at 11:36:35PM -0700, David Miller wrote:
Thanks I'll add the warning fix, but there must be some counter
bug if it tried to grow to order-7, that really shouldn't
be happening.
Good point. A bit of dd-ing shows that I've got a negative value
in xfrm_policy_count[0]
On Mon, May 14, 2007 at 05:07:33PM +1000, Herbert Xu wrote:
Good point. A bit of dd-ing shows that I've got a negative value
in xfrm_policy_count[0] (0xfff6).
In fact the other two directions are bogus too, OUT says 10 and FWD
says 5. The actual values are IN == 2, OUT == 2, FWD == 1.
On Mon, May 14, 2007 at 05:26:57PM +1000, Herbert Xu wrote:
On Mon, May 14, 2007 at 05:07:33PM +1000, Herbert Xu wrote:
Good point. A bit of dd-ing shows that I've got a negative value
in xfrm_policy_count[0] (0xfff6).
In fact the other two directions are bogus too, OUT says 10 and
On Mon, May 14, 2007 at 05:27:55PM +1000, Herbert Xu wrote:
In fact that's a clue. If you add them all up they come out at the
same value. So we're getting the directions mixed up...
Found the problem. It was my own fault in a way :)
[IPSEC]: Check validity of direction in
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 14 May 2007 17:39:41 +1000
[IPSEC]: Check validity of direction in xfrm_policy_byid
The function xfrm_policy_byid takes a dir argument but finds the policy
using the index instead. We only use the dir argument to update the
policy count for
they're expected
to fail after the box has been up for a while. Also, should we try
vmalloc when it does fail?
[IPSEC]: Don't warn if high-order hash resize fails
Multi-page allocations are always likely to fail. Since such failures
are expected and non-critical in xfrm_hash_alloc, we shouldn't warn
