Skip to content
  1. Jul 22, 2020
    • Kuniyuki Iwashima's avatar
      udp: Improve load balancing for SO_REUSEPORT. · efc6b6f6
      Kuniyuki Iwashima authored
      Currently, SO_REUSEPORT does not work well if connected sockets are in a
      UDP reuseport group.
      
      Then reuseport_has_conns() returns true and the result of
      reuseport_select_sock() is discarded. Also, unconnected sockets have the
      same score, hence only does the first unconnected socket in udp_hslot
      always receive all packets sent to unconnected sockets.
      
      So, the result of reuseport_select_sock() should be used for load
      balancing.
      
      The noteworthy point is that the unconnected sockets placed after
      connected sockets in sock_reuseport.socks will receive more packets than
      others because of the algorithm in reuseport_select_sock().
      
          index | connected | reciprocal_scale | result
          ---------------------------------------------
          0     | no        | 20%              | 40%
          1     | no        | 20%              | 20%
          2     | yes       | 20%              | 0%
          3     | no        | 20%              | 40%
          4     | yes       | 20%              | 0%
      
      If most of the sockets are connected, this can be a problem, but it still
      works better than now.
      
      Fixes: acdcecc6
      
       ("udp: correct reuseport selection with connected sockets")
      CC: Willem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarBenjamin Herrenschmidt <benh@amazon.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.co.jp>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      efc6b6f6
    • Kuniyuki Iwashima's avatar
      udp: Copy has_conns in reuseport_grow(). · f2b2c55e
      Kuniyuki Iwashima authored
      If an unconnected socket in a UDP reuseport group connect()s, has_conns is
      set to 1. Then, when a packet is received, udp[46]_lib_lookup2() scans all
      sockets in udp_hslot looking for the connected socket with the highest
      score.
      
      However, when the number of sockets bound to the port exceeds max_socks,
      reuseport_grow() resets has_conns to 0. It can cause udp[46]_lib_lookup2()
      to return without scanning all sockets, resulting in that packets sent to
      connected sockets may be distributed to unconnected sockets.
      
      Therefore, reuseport_grow() should copy has_conns.
      
      Fixes: acdcecc6
      
       ("udp: correct reuseport selection with connected sockets")
      CC: Willem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarBenjamin Herrenschmidt <benh@amazon.com>
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.co.jp>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2b2c55e
  2. Jul 21, 2020
  3. Jul 20, 2020
    • Alexander A. Klimov's avatar
      net: ieee802154: adf7242: Replace HTTP links with HTTPS ones · 19dc3654
      Alexander A. Klimov authored
      Rationale:
      Reduces attack surface on kernel devs opening the links for MITM
      as HTTPS traffic is much harder to manipulate.
      
      Deterministic algorithm:
      For each file:
        If not .svg:
          For each line:
            If doesn't contain `\bxmlns\b`:
              For each link, `\bhttp://[^#
      
       \t\r\n]*(?:\w|/)`:
      	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
                  If both the HTTP and HTTPS versions
                  return 200 OK and serve the same content:
                    Replace HTTP with HTTPS.
      
      Signed-off-by: default avatarAlexander A. Klimov <grandmaster@al2klimov.de>
      Link: https://lore.kernel.org/r/20200719113142.58304-1-grandmaster@al2klimov.de
      
      
      Signed-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      19dc3654
    • Taehee Yoo's avatar
      bonding: check error value of register_netdevice() immediately · 544f287b
      Taehee Yoo authored
      If register_netdevice() is failed, net_device should not be used
      because variables are uninitialized or freed.
      So, the routine should be stopped immediately.
      But, bond_create() doesn't check return value of register_netdevice()
      immediately. That will result in a panic because of using uninitialized
      or freed memory.
      
      Test commands:
          modprobe netdev-notifier-error-inject
          echo -22 > /sys/kernel/debug/notifier-error-inject/netdev/\
      actions/NETDEV_REGISTER/error
          modprobe bonding max_bonds=3
      
      Splat looks like:
      [  375.028492][  T193] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
      [  375.033207][  T193] CPU: 2 PID: 193 Comm: kworker/2:2 Not tainted 5.8.0-rc4+ #645
      [  375.036068][  T193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  375.039673][  T193] Workqueue: events linkwatch_event
      [  375.041557][  T193] RIP: 0010:dev_activate+0x4a/0x340
      [  375.043381][  T193] Code: 40 a8 04 0f 85 db 00 00 00 8b 83 08 04 00 00 85 c0 0f 84 0d 01 00 00 31 d2 89 d0 48 8d 04 40 48 c1 e0 07 48 03 83 00 04 00 00 <48> 8b 48 10 f6 41 10 01 75 08 f0 80 a1 a0 01 00 00 fd 48 89 48 08
      [  375.050267][  T193] RSP: 0018:ffff9f8facfcfdd8 EFLAGS: 00010202
      [  375.052410][  T193] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f8fae6ea000 RCX: 0000000000000006
      [  375.055178][  T193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f8fae6ea000
      [  375.057762][  T193] RBP: ffff9f8fae6ea000 R08: 0000000000000000 R09: 0000000000000000
      [  375.059810][  T193] R10: 0000000000000001 R11: 0000000000000000 R12: ffff9f8facfcfe08
      [  375.061892][  T193] R13: ffffffff883587e0 R14: 0000000000000000 R15: ffff9f8fae6ea580
      [  375.063931][  T193] FS:  0000000000000000(0000) GS:ffff9f8fbae00000(0000) knlGS:0000000000000000
      [  375.066239][  T193] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  375.067841][  T193] CR2: 00007f2f542167a0 CR3: 000000012cee6002 CR4: 00000000003606e0
      [  375.069657][  T193] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  375.071471][  T193] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  375.073269][  T193] Call Trace:
      [  375.074005][  T193]  linkwatch_do_dev+0x4d/0x50
      [  375.075052][  T193]  __linkwatch_run_queue+0x10b/0x200
      [  375.076244][  T193]  linkwatch_event+0x21/0x30
      [  375.077274][  T193]  process_one_work+0x252/0x600
      [  375.078379][  T193]  ? process_one_work+0x600/0x600
      [  375.079518][  T193]  worker_thread+0x3c/0x380
      [  375.080534][  T193]  ? process_one_work+0x600/0x600
      [  375.081668][  T193]  kthread+0x139/0x150
      [  375.082567][  T193]  ? kthread_park+0x90/0x90
      [  375.083567][  T193]  ret_from_fork+0x22/0x30
      
      Fixes: e826eafa
      
       ("bonding: Call netif_carrier_off after register_netdevice")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      544f287b
    • Russell King's avatar
      arm64: dts: clearfog-gt-8k: fix switch link configuration · 7c6719a1
      Russell King authored
      The commit below caused a regression for clearfog-gt-8k, where the link
      between the switch and the host does not come up.
      
      Investigation revealed two issues:
      - MV88E6xxx DSA no longer allows an in-band link to come up as the link
        is programmed to be forced down. Commit "net: dsa: mv88e6xxx: fix
        in-band AN link establishment" addresses this.
      
      - The dts configured dissimilar link modes at each end of the host to
        switch link; the host was configured using a fixed link (so has no
        in-band status) and the switch was configured to expect in-band
        status.
      
      With both issues fixed, the regression is resolved.
      
      Fixes: 34b5e6a3
      
       ("net: dsa: mv88e6xxx: Configure MAC when using fixed link")
      Reported-by: default avatarMartin Rowe <martin.p.rowe@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c6719a1
    • Russell King's avatar
      net: dsa: mv88e6xxx: fix in-band AN link establishment · fad58190
      Russell King authored
      If in-band negotiation or fixed-link modes are specified for a DSA
      port, the DSA code will force the link down during initialisation. For
      fixed-link mode, this is fine, as phylink will manage the link state.
      However, for in-band mode, phylink expects the PCS to detect link,
      which will not happen if the link is forced down.
      
      There is a related issue that in in-band mode, the link could come up
      while we are making configuration changes, so we should force the link
      down prior to reconfiguring the interface mode.
      
      This patch addresses both issues.
      
      Fixes: 3be98b2d
      
       ("net: dsa: Down cpu/dsa ports phylink will control")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fad58190
    • David S. Miller's avatar
      Merge branch 'net-smc-fixes' · a463fa2c
      David S. Miller authored
      
      
      Karsten Graul says:
      
      ====================
      net/smc: fixes 2020-07-16
      
      Please apply the following patch series for smc to netdev's net tree.
      
      The patches address problems caused by late or unexpected link layer
      control packets, dma sync calls for unmapped memory, freed buffers
      that are not removed from the buffer list and a possible null pointer
      access that results in a crash.
      
      v1->v2: in patch 4, improve patch description and correct the comment
              for the new mutex
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a463fa2c
    • Karsten Graul's avatar
      net/smc: fix restoring of fallback changes · 1ad24058
      Karsten Graul authored
      
      
      When a listen socket is closed then all non-accepted sockets in its
      accept queue are to be released. Inside __smc_release() the helper
      smc_restore_fallback_changes() restores the changes done to the socket
      without to check if the clcsocket has a file set. This can result in
      a crash. Fix this by checking the file pointer first.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: f536dffc
      
       ("net/smc: fix closing of fallback SMC sockets")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ad24058
    • Karsten Graul's avatar
      net/smc: remove freed buffer from list · fd7f3a74
      Karsten Graul authored
      
      
      Two buffers are allocated for each SMC connection. Each buffer is
      added to a buffer list after creation. When the second buffer
      allocation fails, the first buffer is freed but not deleted from
      the list. This might result in crashes when another connection picks
      up the freed buffer later and starts to work with it.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: 6511aad3
      
       ("net/smc: change smc_buf_free function parameters")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd7f3a74
    • Karsten Graul's avatar
      net/smc: do not call dma sync for unmapped memory · 741a49a4
      Karsten Graul authored
      
      
      The dma related ...sync_sg... functions check the link state before the
      dma function is actually called. But the check in smc_link_usable()
      allows links in ACTIVATING state which are not yet mapped to dma memory.
      Under high load it may happen that the sync_sg functions are called for
      such a link which results in an debug output like
         DMA-API: mlx5_core 0002:00:00.0: device driver tries to sync
         DMA memory it has not allocated [device address=0x0000000103370000]
         [size=65536 bytes]
      To fix that introduce a helper to check for the link state ACTIVE and
      use it where appropriate. And move the link state update to ACTIVATING
      to the end of smcr_link_init() when most initial setup is done.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: d854fcbf
      
       ("net/smc: add new link state and related helpers")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      741a49a4
    • Karsten Graul's avatar
      net/smc: fix handling of delete link requests · b9979c2e
      Karsten Graul authored
      
      
      As smc client the delete link requests are assigned to the flow when
      _any_ flow is active. This may break other flows that do not expect
      delete link requests during their handling. Fix that by assigning the
      request only when an add link flow is active. With that fix the code
      for smc client and smc server is the same, so remove the separate
      handling.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: 9ec6bf19
      
       ("net/smc: llc_del_link_work and use the LLC flow for delete link")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9979c2e
    • Karsten Graul's avatar
      net/smc: move add link processing for new device into llc layer · c48254fa
      Karsten Graul authored
      
      
      When a new ib device is up smc will send an add link invitation to the
      peer if needed. This is currently done with rudimentary flow control.
      Under high workload these add link invitations can disturb other llc
      flows because they arrive unexpected. Fix this by integrating the
      invitations into the normal llc event flow and handle them as a flow.
      While at it, check for already assigned requests in the flow before
      the new add link request is assigned.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: 1f90a05d
      
       ("net/smc: add smcr_port_add() and smcr_link_up() processing")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c48254fa
    • Karsten Graul's avatar
      net/smc: drop out-of-flow llc response messages · 2ff08678
      Karsten Graul authored
      
      
      To be save from unexpected or late llc response messages check if the
      arrived message fits to the current flow type and drop out-of-flow
      messages. And drop it when there is already a response assigned to
      the flow.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: ef79d439
      
       ("net/smc: process llc responses in tasklet context")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ff08678
    • Karsten Graul's avatar
      net/smc: protect smc ib device initialization · 63673597
      Karsten Graul authored
      
      
      Before an smc ib device is used the first time for an smc link it is
      lazily initialized. When there are 2 active link groups and a new ib
      device is brought online then it might happen that 2 link creations run
      in parallel and enter smc_ib_setup_per_ibdev(). Both allocate new send
      and receive completion queues on the device, but only one set of them
      keeps assigned and the other leaks.
      Fix that by protecting the setup and cleanup code using a mutex.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: f3c1dedd
      
       ("net/smc: separate function for link initialization")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63673597
    • Karsten Graul's avatar
      net/smc: fix link lookup for new rdma connections · 7df8bcb5
      Karsten Graul authored
      
      
      For new rdma connections the SMC server assigns the link and sends the
      link data in the clc accept message. To match the correct link use not
      only the qp_num but also the gid and the mac of the links. If there are
      equal qp_nums for different links the wrong link would be chosen.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: 0fb0b02b
      
       ("net/smc: adapt SMC client code to use the LLC flow")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7df8bcb5
    • Karsten Graul's avatar
      net/smc: clear link during SMC client link down processing · 68fd8942
      Karsten Graul authored
      
      
      In a link-down condition we notify the SMC server and expect that the
      server will finally trigger the link clear processing on the client
      side. This could fail when anything along this notification path goes
      wrong. Clear the link as part of SMC client link-down processing to
      prevent dangling links.
      
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Fixes: 541afa10
      
       ("net/smc: add smcr_port_err() and smcr_link_down() processing")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68fd8942