netdev - Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Dec 2015 09:10:24 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Willy Tarreau <w@....eu>
Cc:	Tom Herbert <tom@...bertland.com>,
	Tolga Ceylan <tolga.ceylan@...il.com>,
	Aaron Conole <aconole@...heb.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/1] net: Add SO_REUSEPORT_LISTEN_OFF socket option as
 drain mode

On Tue, 2015-12-15 at 17:14 +0100, Willy Tarreau wrote:
> Hi Eric,
> 
> On Wed, Nov 11, 2015 at 05:09:01PM -0800, Eric Dumazet wrote:
> > On Wed, 2015-11-11 at 10:43 -0800, Eric Dumazet wrote:
> > > On Wed, 2015-11-11 at 10:23 -0800, Tom Herbert wrote:
> > > 
> > > > How about doing this in shutdown called for a listener?
> > > 
> > > Seems a good idea, I will try it, thanks !
> > > 
> > 
> > Arg, I forgot about this shutdown() discussion we had recently
> > with Oracle guys.
> > 
> > It is currently used in linux to unblock potential threads in accept()
> > system call.
> > 
> > This would prevent syn_recv sockets to be finally accepted.
> 
> I had a conversation with an haproxy user who's concerned with the
> connection drops during the reload operation and we stumbled upon
> this thread. I was considering improving shutdown() as well for this
> as haproxy already performs a shutdown(RD) during a "pause" operation
> (ie: workaround for kernels missing SO_REUSEPORT).
> 
> And I found that the code clearly doesn't make this possible since
> shutdown(RD) flushes the queue and stops the listening.
> 
> However I found what I consider an elegant solution which works
> pretty well : by simply adding a test in compute_score(), we can
> ensure that a previous socket ranks lower than the current ones,
> and is never considered as long as the new ones are present. Here I
> achieved this using setsockopt(SO_LINGER). The old process just has
> to do this with a non-zero value on the socket it wants to put into
> lingering mode and that's all.
> 
> I find this elegant since it keeps the same semantics as for a
> connected socket in that it avoids killing the queue, and that it
> doesn't change the behaviour for existing applications. It just
> turns out that listening sockets are set up without any lingering
> by default so we don't need to add any new socket options nor
> anything.
> 
> Please let me know what you think about it (patch attached), if
> it's accepted it's trivial to adapt haproxy to this new behaviour.

Well, problem is : some applications use LINGER on the listener,
you can not really hijack this flag.

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html