aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEric Dumazet <eric.dumazet@gmail.com>2010-11-24 09:15:27 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2011-05-09 15:55:36 -0700
commit6034a281f077b621859fb7b2f362fc9d693ea218 (patch)
treefe8cba40bbbd0643fefd1e17c7bac5c095390a99
parent6019f3837946cd5872ed473cd492d90c49228ee3 (diff)
af_unix: limit unix_tot_inflight
commit 9915672d41273f5b77f1b3c29b391ffb7732b84b upstream. Vegard Nossum found a unix socket OOM was possible, posting an exploit program. My analysis is we can eat all LOWMEM memory before unix_gc() being called from unix_release_sock(). Moreover, the thread blocked in unix_gc() can consume huge amount of time to perform cleanup because of huge working set. One way to handle this is to have a sensible limit on unix_tot_inflight, tested from wait_for_unix_gc() and to force a call to unix_gc() if this limit is hit. This solves the OOM and also reduce overall latencies, and should not slowdown normal workloads. Reported-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r--net/unix/garbage.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 97d1a380423..cb72e91f148 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -269,9 +269,16 @@ static void inc_inflight_move_tail(struct unix_sock *u)
}
static bool gc_in_progress = false;
+#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
{
+ /*
+ * If number of inflight sockets is insane,
+ * force a garbage collect right now.
+ */
+ if (unix_tot_inflight > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
+ unix_gc();
wait_event(unix_gc_wait, gc_in_progress == false);
}