1. 06 Apr, 2017 5 commits
    • David Howells's avatar
      rxrpc: Handle temporary errors better in rxkad security · ef68622d
      David Howells authored
      In the rxkad security module, when we encounter a temporary error (such as
      ENOMEM) from which we could conceivably recover, don't abort the
      connection, but rather permit retransmission of the relevant packets to
      induce a retry.
      
      Note that I'm leaving some places that could be merged together to insert
      tracing in the next patch.
      
      Signed-off-by; David Howells <dhowells@redhat.com>
      ef68622d
    • David Howells's avatar
      rxrpc: Note a successfully aborted kernel operation · 84a4c09c
      David Howells authored
      Make rxrpc_kernel_abort_call() return an indication as to whether it
      actually aborted the operation or not so that kafs can trace the failure of
      the operation.  Note that 'success' in this context means changing the
      state of the call, not necessarily successfully transmitting an ABORT
      packet.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      84a4c09c
    • David Howells's avatar
      rxrpc: Use negative error codes in rxrpc_call struct · 3a92789a
      David Howells authored
      Use negative error codes in struct rxrpc_call::error because that's what
      the kernel normally deals with and to make the code consistent.  We only
      turn them positive when transcribing into a cmsg for userspace recvmsg.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      3a92789a
    • Jarod Wilson's avatar
      bonding: attempt to better support longer hw addresses · faeeb317
      Jarod Wilson authored
      People are using bonding over Infiniband IPoIB connections, and who knows
      what else. Infiniband has a hardware address length of 20 octets
      (INFINIBAND_ALEN), and the network core defines a MAX_ADDR_LEN of 32.
      Various places in the bonding code are currently hard-wired to 6 octets
      (ETH_ALEN), such as the 3ad code, which I've left untouched here. Besides,
      only alb is currently possible on Infiniband links right now anyway, due
      to commit 1533e773, so the alb code is where most of the changes are.
      
      One major component of this change is the addition of a bond_hw_addr_copy
      function that takes a length argument, instead of using ether_addr_copy
      everywhere that hardware addresses need to be copied about. The other
      major component of this change is converting the bonding code from using
      struct sockaddr for address storage to struct sockaddr_storage, as the
      former has an address storage space of only 14, while the latter is 128
      minus a few, which is necessary to support bonding over device with up to
      MAX_ADDR_LEN octet hardware addresses. Additionally, this probably fixes
      up some memory corruption issues with the current code, where it's
      possible to write an infiniband hardware address into a sockaddr declared
      on the stack.
      
      Lightly tested on a dual mlx4 IPoIB setup, which properly shows a 20-octet
      hardware address now:
      
      $ cat /proc/net/bonding/bond0
      Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
      
      Bonding Mode: fault-tolerance (active-backup) (fail_over_mac active)
      Primary Slave: mlx4_ib0 (primary_reselect always)
      Currently Active Slave: mlx4_ib0
      MII Status: up
      MII Polling Interval (ms): 100
      Up Delay (ms): 100
      Down Delay (ms): 100
      
      Slave Interface: mlx4_ib0
      MII Status: up
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 0
      Permanent HW addr:
      80:00:02:08:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:1d:67:01
      Slave queue ID: 0
      
      Slave Interface: mlx4_ib1
      MII Status: up
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 0
      Permanent HW addr:
      80:00:02:09:fe:80:00:00:00:00:00:01:e4:1d:2d:03:00:1d:67:02
      Slave queue ID: 0
      
      Also tested with a standard 1Gbps NIC bonding setup (with a mix of
      e1000 and e1000e cards), running LNST's bonding tests.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: netdev@vger.kernel.org
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      faeeb317
    • Edward Cree's avatar
      sfc: don't insert mc_list on low-latency firmware if it's too long · 148cbab6
      Edward Cree authored
      If the mc_list is longer than 256 addresses, we enter mc_promisc mode.
      If we're in mc_promisc mode and the firmware doesn't support cascaded
       multicast, normally we also insert our mc_list, to prevent stealing by
       another VI.  However, if the mc_list was too long, this isn't really
       helpful - the MC groups that didn't fit in the list can still get
       stolen, and having only some of them stealable will probably cause
       more confusing behaviour than having them all stealable.  Since
       inserting 256 multicast filters takes a long time and can lead to MCDI
       state machine timeouts, just skip the mc_list insert in this overflow
       condition.
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      148cbab6
  2. 05 Apr, 2017 35 commits