Harald Welte <laforge@xxxxxxxxxxxxx> wrote:
>
> what's worrying me is the part above... how would skb_checksum_help
> directly end up in copy_from_user()?
That'll be leftover gunk on the stack. Enabling frame pointers makes that
go away.
> > swapper: page allocation failure. order:1, mode:0x20
> > [<c013d770>] __alloc_pages+0x2da/0x34a
> > [<c013d805>] __get_free_pages+0x25/0x3f
> > [<c0140e28>] kmem_getpages+0x2b/0xdc
> > [<c0141bfc>] kfree_skbmem+0x24/0x2c
> > [<c0141c5d>] cache_grow+0xe5/0x2a4
> > [<c0141f8a>] cache_grow+0x146/0x2a4
> > [<c0295917>] cache_alloc_refill+0x1cf/0x29f
> > [<c014262a>] __kmalloc+0x85/0x8c
> > [<c02681f1>] tcp_transmit_skb+0x411/0x68a
> > [<c0296621>] alloc_skb+0x47/0xe0
> > [<c026875e>] tcp_write_xmit+0x16d/0x2d6
> > [<c01da1ac>] skb_copy+0x33/0xde
> > [<c026ca5b>] copy_from_user+0x42/0x6e
>
> Does anybody have a clue what's going on?
Networking tried to do an atomic 1-order allocation and there were no
1-order pages available in the free page pools. It's pretty much
unavoidable, and the caller simply needs to handle it - presumably by
dropping the packet.
Its frequency can be reduced by increasing /proc/sys/vm/min_free_kbytes.
It can be eliminated by using GFP_KERNEL. It can be hugely reduced by
sticking to 0-order allocations.
I wouldn't worry about this unless someone is seeing a lot of them (a
significant number of packets are getting dropped)
|