netdev - [PATCH net-next 00/10] rxrpc: Development

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

Date:   Wed, 01 Aug 2018 13:58:45 +0100
From:   David Howells <dhowells@...hat.com>
To:     netdev@...r.kernel.org
Cc:     dhowells@...hat.com, linux-afs@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH net-next 00/10] rxrpc: Development


Here are some patches that add some more tracepoints to AF_RXRPC and fix
some issues therein.  The most significant points are:

 (1) Display the call timeout information in /proc/net/rxrpc/calls.

 (2) Save the call's debug_id in the rxrpc_channel struct so that it can be
     used in traces after the rxrpc_call struct has been destroyed.

 (3) Increase the size of the kAFS Rx window from 32 to 63 to be about the
     same as the Auristor server.

 (4) Propose the terminal ACK for a client call after it has received all
     its data to be transmitted after a short interval so that it will get
     transmitted if not first superseded by a new call on the same channel.

 (5) Flush ACKs during the data reception if we detect that we've run out
     of data.[*]

 (6) Trace successful packet transmission and softirq to process context
     socket notification.

[*] Note that on a uncontended gigabit network, rxrpc runs in to trouble
    with ACK packets getting batched together (up to ~32 at a time)
    somewhere between the IP transmit queue on the client and the ethernet
    receive queue on the server.

    I can see the kernel afs filesystem client and Auristor userspace
    server stalling occasionally on a 512MB single read.  Sticking
    tracepoints in the network driver at either end seems to show that,
    although the ACK transmissions made by the client are reasonably spaced
    timewise, the received ACKs come in batches from the network card on
    the server.

    I'm not sure what, if anything, can be done about this.


The patches are tagged here:

	git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
	rxrpc-next-20180801

and can also be found on this branch:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-next

David
---
David Howells (9):
      rxrpc: Display call expect-receive-by timeout in proc
      rxrpc: Show some more information through /proc files
      rxrpc: Fix the trace for terminal ACK (re)transmission
      rxrpc: Trace packet transmission
      rxrpc: Fix ACK proposal tracepoint
      rxrpc: Trace socket notification
      rxrpc: Increase the size of a call's Rx window
      rxrpc: Propose, but don't immediately transmit, the final ACK for a call
      rxrpc: Transmit more ACKs during data reception

YueHaibing (1):
      rxrpc: remove redundant variables 'sp' and 'did_discard'


 include/trace/events/rxrpc.h |  129 ++++++++++++++++++++++++++++++------------
 net/rxrpc/ar-internal.h      |    4 +
 net/rxrpc/call_event.c       |    2 -
 net/rxrpc/conn_client.c      |    3 -
 net/rxrpc/conn_event.c       |   17 ++++--
 net/rxrpc/input.c            |   15 ++++-
 net/rxrpc/local_event.c      |    5 +-
 net/rxrpc/output.c           |   32 ++++++++--
 net/rxrpc/proc.c             |   23 ++++++-
 net/rxrpc/recvmsg.c          |   23 ++++++-
 net/rxrpc/rxkad.c            |    7 ++
 11 files changed, 193 insertions(+), 67 deletions(-)