[lkml]   [2011]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] [53/139] af_unix: limit unix_tot_inflight
2.6.35-longterm review patch.  If anyone has any objections, please let me know.


From: Eric Dumazet <>

[ Upstream commit 9915672d41273f5b77f1b3c29b391ffb7732b84b ]

Vegard Nossum found a unix socket OOM was possible, posting an exploit

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 <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Andi Kleen <>

net/unix/garbage.c | 7 +++++++
1 file changed, 7 insertions(+)

Index: linux-2.6.35.y/net/unix/garbage.c
--- linux-2.6.35.y.orig/net/unix/garbage.c
+++ linux-2.6.35.y/net/unix/garbage.c
@@ -259,9 +259,16 @@ static void inc_inflight_move_tail(struc

static bool gc_in_progress = false;

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

 \ /
  Last update: 2011-02-02 01:47    [W:0.322 / U:4.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site