Re: [PATCH] net: use __GFP_NORETRY for high order allocations

David Miller [off-list ref] writes:

From: Eric Dumazet <redacted>
Date: Thu, 06 Feb 2014 10:42:42 -0800

quoted

From: Eric Dumazet <edumazet@google.com>

sock_alloc_send_pskb() & sk_page_frag_refill()
have a loop trying high order allocations to prepare
skb with low number of fragments as this increases performance.

Problem is that under memory pressure/fragmentation, this can
trigger OOM while the intent was only to try the high order
allocations, then fallback to order-0 allocations.

We had various reports from unexpected regressions.

According to David, setting __GFP_NORETRY should be fine,
as the asynchronous compaction is still enabled, and this
will prevent OOM from kicking as in :

 ...

quoted

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David Rientjes <rientjes@google.com>

Applied, do we want this for -stable?

The first hunk goes back to 3.12 and the second hunk goes back to 3.8.

I think so.    The change is safe and this class of problem can cause an
external attack to trigger an OOM on your box, by controlling the packet
flow.

Eric

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 07 Feb 2014 16:22:56 -0800

David Miller [off-list ref] writes:

quoted

From: Eric Dumazet <redacted>
Date: Thu, 06 Feb 2014 10:42:42 -0800

quoted

From: Eric Dumazet <edumazet@google.com>

sock_alloc_send_pskb() & sk_page_frag_refill()
have a loop trying high order allocations to prepare
skb with low number of fragments as this increases performance.

Problem is that under memory pressure/fragmentation, this can
trigger OOM while the intent was only to try the high order
allocations, then fallback to order-0 allocations.

We had various reports from unexpected regressions.

According to David, setting __GFP_NORETRY should be fine,
as the asynchronous compaction is still enabled, and this
will prevent OOM from kicking as in :

 ...

quoted

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David Rientjes <rientjes@google.com>

Applied, do we want this for -stable?

The first hunk goes back to 3.12 and the second hunk goes back to 3.8.

I think so.    The change is safe and this class of problem can cause an
external attack to trigger an OOM on your box, by controlling the packet
flow.

Great, I'm working integrating this into my -stable queue right now.