summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorEric Dumazet <eric.dumazet@gmail.com>2010-11-24 09:15:27 -0800
committerDavid S. Miller <davem@davemloft.net>2010-11-24 09:15:27 -0800
commit9915672d41273f5b77f1b3c29b391ffb7732b84b (patch)
tree191dbf657535e49265be7664755890630e69e329 /include
parentcf41a51db89850033efc11c18a5257de810b5417 (diff)
downloadlinux-3.10-9915672d41273f5b77f1b3c29b391ffb7732b84b.tar.gz
linux-3.10-9915672d41273f5b77f1b3c29b391ffb7732b84b.tar.bz2
linux-3.10-9915672d41273f5b77f1b3c29b391ffb7732b84b.zip
af_unix: limit unix_tot_inflight
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>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions