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:	Wed, 11 Nov 2015 09:23:30 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	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 Wed, 2015-11-11 at 09:05 -0800, Tom Herbert wrote:
> On Tue, Nov 10, 2015 at 10:19 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > On Tue, 2015-11-10 at 21:41 -0800, Tom Herbert wrote:
> >> Tolga, are you still planning to respin this patch (when tree opens?)
> >
> > I was planning to add an union on skc_tx_queue_mapping and
> > sk_max_ack_backlog, so that adding a check on sk_max_ack_backlog in
> > listener lookup would not add an additional cache line miss.
> >
> > This would remove false sharing because sk_ack_backlog is often dirtied
> > when a socket is added into accept queue.
> >
> That's sounds like good fixes, but my question was more about the
> problem originally described by Tolga where we are transitioning
> processing for a listener port from one process to another. I think
> the conclusion in this thread was to modify the code so that
> listen(fd, 0) would stop new connections from being assigned to a
> socket (as opposed to explicit SO_REUSEPORT_LISTEN_OFF option). Does
> this still seem reasonable?

Actually listen(fd, 0) is not going to work well :

For request_sock that were created (by incoming SYN packet) before this
listen(fd, 0) call, the 3rd packet (ACK coming from client) would not be
able to create a child attached to this listener.

sk_acceptq_is_full() test in tcp_v4_syn_recv_sock() would simply drop
the thing.

I was mainly objecting adding yet another socket option.

Maybe setsockopt(... SO_REUSEPORT, &off, sizeof(off)) could detect the
condition automatically ?

(I am not sure current behavior of setting sk->sk_reuseport = valbool;
is correct if valbool==0 and current sk_reuseport is 1)



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