1. 20 May, 2020 1 commit
  2. 11 May, 2020 1 commit
    • David Howells's avatar
      rxrpc: Fix the excessive initial retransmission timeout · c410bf01
      David Howells authored
      rxrpc currently uses a fixed 4s retransmission timeout until the RTT is
      sufficiently sampled.  This can cause problems with some fileservers with
      calls to the cache manager in the afs filesystem being dropped from the
      fileserver because a packet goes missing and the retransmission timeout is
      greater than the call expiry timeout.
      
      Fix this by:
      
       (1) Copying the RTT/RTO calculation code from Linux's TCP implementation
           and altering it to fit rxrpc.
      
       (2) Altering the various users of the RTT to make use of the new SRTT
           value.
      
       (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO
           value instead (which is needed in jiffies), along with a backoff.
      
      Notes:
      
       (1) rxrpc provides RTT samples by matching the serial numbers on outgoing
           DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets
           against the reference serial number in incoming REQUESTED ACK and
           PING-RESPONSE ACK packets.
      
       (2) Each packet that is transmitted on an rxrpc connection gets a new
           per-connection serial number, even for retransmissions, so an ACK can
           be cross-referenced to a specific trigger packet.  This allows RTT
           information to be drawn from retransmitted DATA packets also.
      
       (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than
           on an rxrpc_call because many RPC calls won't live long enough to
           generate more than one sample.
      
       (4) The calculated SRTT value is in units of 8ths of a microsecond rather
           than nanoseconds.
      
      The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers.
      
      Fixes: 17926a79 ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      c410bf01
  3. 29 Apr, 2020 2 commits
    • Florian Westphal's avatar
      mptcp: replace mptcp_disconnect with a stub · 42c556fe
      Florian Westphal authored
      Paolo points out that mptcp_disconnect is bogus:
      "lock_sock(sk);
      looks suspicious (lock should be already held by the caller)
      And call to: tcp_disconnect(sk, flags); too, sk is not a tcp
      socket".
      
      ->disconnect() gets called from e.g. inet_stream_connect when
      one tries to disassociate a connected socket again (to re-connect
      without closing the socket first).
      MPTCP however uses mptcp_stream_connect, not inet_stream_connect,
      for the mptcp-socket connect call.
      
      inet_stream_connect only gets called indirectly, for the tcp socket,
      so any ->disconnect() calls end up calling tcp_disconnect for that
      tcp subflow sk.
      
      This also explains why syzkaller has not yet reported a problem
      here.  So for now replace this with a stub that doesn't do anything.
      
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/14Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42c556fe
    • Jason Yan's avatar
      net: dsa: mv88e6xxx: remove duplicate assignment of struct members · 98123074
      Jason Yan authored
      These struct members named 'phylink_validate' was assigned twice:
      
      static const struct mv88e6xxx_ops mv88e6190_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6190x_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390x_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6191_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      static const struct mv88e6xxx_ops mv88e6290_ops = {
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      	......
      	.phylink_validate = mv88e6390_phylink_validate,
      };
      
      Remove all the first one and leave the second one which are been used in
      fact. Be aware that for 'mv88e6190x_ops' the assignment functions is
      different while the others are all the same. This fixes the following
      coccicheck warning:
      
      drivers/net/dsa/mv88e6xxx/chip.c:3911:48-49: phylink_validate: first
      occurrence line 3965, second occurrence line 3967
      drivers/net/dsa/mv88e6xxx/chip.c:3970:49-50: phylink_validate: first
      occurrence line 4024, second occurrence line 4026
      drivers/net/dsa/mv88e6xxx/chip.c:4029:48-49: phylink_validate: first
      occurrence line 4082, second occurrence line 4085
      drivers/net/dsa/mv88e6xxx/chip.c:4184:48-49: phylink_validate: first
      occurrence line 4238, second occurrence line 4242
      
      Fixes: 4262c38d ("net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family members")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98123074
  4. 28 Apr, 2020 2 commits
    • YueHaibing's avatar
      net/x25: Fix null-ptr-deref in x25_disconnect · 8999dc89
      YueHaibing authored
      We should check null before do x25_neigh_put in x25_disconnect,
      otherwise may cause null-ptr-deref like this:
      
       #include <sys/socket.h>
       #include <linux/x25.h>
      
       int main() {
          int sck_x25;
          sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
          close(sck_x25);
          return 0;
       }
      
      BUG: kernel NULL pointer dereference, address: 00000000000000d8
      CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
      RIP: 0010:x25_disconnect+0x91/0xe0
      Call Trace:
       x25_release+0x18a/0x1b0
       __sock_release+0x3d/0xc0
       sock_close+0x13/0x20
       __fput+0x107/0x270
       ____fput+0x9/0x10
       task_work_run+0x6d/0xb0
       exit_to_usermode_loop+0x102/0x110
       do_syscall_64+0x23c/0x260
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
      Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8999dc89
    • Gavin Shan's avatar
      net/ena: Fix build warning in ena_xdp_set() · caec6619
      Gavin Shan authored
      This fixes the following build warning in ena_xdp_set(), which is
      observed on aarch64 with 64KB page size.
      
         In file included from ./include/net/inet_sock.h:19,
            from ./include/net/ip.h:27,
            from drivers/net/ethernet/amazon/ena/ena_netdev.c:46:
         drivers/net/ethernet/amazon/ena/ena_netdev.c: In function         \
         ‘ena_xdp_set’:                                                    \
         drivers/net/ethernet/amazon/ena/ena_netdev.c:557:6: warning:      \
         format ‘%lu’                                                      \
         expects argument of type ‘long unsigned int’, but argument 4      \
         has type ‘int’                                                    \
         [-Wformat=] "Failed to set xdp program, the current MTU (%d) is   \
         larger than the maximum allowed MTU (%lu) while xdp is on",
      Signed-off-by: default avatarGavin Shan <gshan@redhat.com>
      Acked-by: default avatarShay Agroskin <shayagr@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      caec6619
  5. 27 Apr, 2020 20 commits
  6. 26 Apr, 2020 2 commits
  7. 25 Apr, 2020 12 commits