netdev - Re: [PATCH net-next] net: preserve sock reference when scrubbing the skb.

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]

Message-ID: <20180627123155.GW19565@plex.lan>
Date:   Wed, 27 Jun 2018 09:31:55 -0300
From:   Flavio Leitner <fbl@...hat.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        David Miller <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>,
        NetFilter <netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: preserve sock reference when scrubbing the
 skb.

On Tue, Jun 26, 2018 at 06:28:27PM -0700, Cong Wang wrote:
> On Tue, Jun 26, 2018 at 5:39 PM Flavio Leitner <fbl@...hat.com> wrote:
> >
> > On Tue, Jun 26, 2018 at 05:29:51PM -0700, Cong Wang wrote:
> > > On Tue, Jun 26, 2018 at 4:33 PM Flavio Leitner <fbl@...hat.com> wrote:
> > > >
> > > > It is still isolated, the sk carries the netns info and it is
> > > > orphaned when it re-enters the stack.
> > >
> > > Then what difference does your patch make?
> >
> > Don't forget it is fixing two issues.
> 
> Sure. I am only talking about TSQ from the very beginning.
> Let me rephrase my above question:
> What difference does your patch make to TSQ?

It avoids burstiness.

> > > Before your patch:
> > > veth orphans skb in its xmit
> > >
> > > After your patch:
> > > RX orphans it when re-entering stack (as you claimed, I don't know)
> >
> > ip_rcv, and equivalents.
> 
> ip_rcv() is L3, we enter a stack from L1. So your above claim is incorrect. :)

Maybe you found a problem, could you please point me to where in
between L1 to L3 the socket is relevant?


> > > And for veth pair:
> > > xmit from one side is RX for the other side
> > > So, where is the queueing? Where is the buffer bloat? GRO list??
> >
> > CPU backlog.
> 
> Yeah, but this is never targeted by TSQ:
> 
>         tcp_limit_output_bytes limits the number of bytes on qdisc
>         or device to reduce artificial RTT/cwnd and reduce bufferbloat.
> 
> which means you have to update Documentation/networking/ip-sysctl.txt
> too.

How it is never targeted? Whole point is to avoid queueing traffic.
Would you be okay if I include this chunk?

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ce8fbf5aa63c..f4c042be0216 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -733,11 +733,11 @@ tcp_limit_output_bytes - INTEGER
 	Controls TCP Small Queue limit per tcp socket.
 	TCP bulk sender tends to increase packets in flight until it
 	gets losses notifications. With SNDBUF autotuning, this can
-	result in a large amount of packets queued in qdisc/device
-	on the local machine, hurting latency of other flows, for
-	typical pfifo_fast qdiscs.
-	tcp_limit_output_bytes limits the number of bytes on qdisc
-	or device to reduce artificial RTT/cwnd and reduce bufferbloat.
+	result in a large amount of packets queued on the local machine
+	(e.g.: qdiscs, CPU backlog, or device) hurting latency of other
+	flows, for typical pfifo_fast qdiscs.  tcp_limit_output_bytes
+	limits the number of bytes on qdisc or device to reduce artificial
+	RTT/cwnd and reduce bufferbloat.
 	Default: 262144
 
 tcp_challenge_ack_limit - INTEGER


-- 
Flavio