linux-kernel - Re: [PATCH 0/3] Namespaceify tcp keepalive machinery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 10 Jan 2016 17:32:36 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	kernel@...p.com
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	edumazet@...gle.com, ebiederm@...ssion.com, fan.du@...el.com,
	kaber@...sh.net, jmorris@...ei.org, alexander.h.duyck@...hat.com,
	kuznet@....inr.ac.ru, operations@...eground.com
Subject: Re: [PATCH 0/3] Namespaceify tcp keepalive machinery

From: Nikolay Borisov <kernel@...p.com>
Date: Thu,  7 Jan 2016 16:38:42 +0200

> The following patch series enables the tcp keepalive mechanism
> to be configured per net namespace. This is especially useful
> if you have multiple containers hosted on one node and one of 
> them is under DoS-  in such situations one thing which could 
> be done is to configure the tcp keepalive settings such that 
> connections for that particular container are being reset 
> faster.
> 
> Another scenario where not being able to control those knob
> comes per container is problematic is occurs the value of 
> net.netfilter.nf_conntrack_tcp_timeout_established is set
> below the keepalive interval, in such situations the server won't 
> send an RST packet resulting in applications not trying to 
> reconnect and stale connection waiting. Changing the global 
> keepalive value is a possible solution but it might interfere
> with other containers. 
> 
> The three patches gradually convert each of the affected knobs
> to be per netns. I thought it would be easier for review than 
> put everything in one patch. If people deem it more appropriate 
> to squash everything in one patch (maybe after review) I'd
> be more than happy to do it. 
> 
> The patches have been compile-tested on 4.4 and functionally 
> tested on 3.12 and they work as expected. 
> 
> These are based off 4.4-rc8

Series applied, thanks.