netdev - Re: TCP stops sending packets over loopback on 4.10-rc3?

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, 25 Jan 2017 06:25:11 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Josef Bacik <jbacik@...com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        Lawrence Brakmo <brakmo@...com>,
        Kernel Team <kernel-team@...com>
Subject: Re: TCP stops sending packets over loopback on 4.10-rc3?

On Wed, 2017-01-25 at 09:14 -0500, Josef Bacik wrote:
> On Tue, Jan 24, 2017 at 9:07 AM, Eric Dumazet <eric.dumazet@...il.com> 

> > 
> > git grep -n SOCK_QUEUE_SHRUNK
> > 
> > -> tcp_check_space()
> 
> But tcp_check_space() doesn't actually reduce sk_wmem_queued from what 
> I can see.  The only places that appear to reduce it are tcp_trim_head, 
> which is only called in the retransmit path, and sk_wmem_free_skb, 
> which seems to be right,

This is exactly how it works.

We free a bunch of skbs (an ACK can acknowledge dozens of them), and set
the SOCK_QUEUE_SHRUNK.

Then later, tcp_check_space() is called once and check if the bit was
set by a prior call to tcp_trim_head() or full skb freeing.

>  but I added a trace_printk() in it to see if 
> it was firing during my test and it never fires.  So we _appear_ to 
> only ever be incrementing this counter, but never decrementing it.  I'm 
> doing a bunch of tracing trying to figure out what is going on here but 
> so far nothing is popping which is starting to make me think ftrace is 
> broken.  Thanks,
> 

Just to make sure, are you telling use native/standard TCP is broken
over loopback, or is that only when using an additional kernel module ?