1. 21 Jul, 2021 7 commits
    • Arnd Bergmann's avatar
      net: ixp46x: fix ptp build failure · 161dcc02
      Arnd Bergmann authored
      The rework of the ixp46x cpu detection left the network driver in
      a half broken state:
      
      drivers/net/ethernet/xscale/ptp_ixp46x.c: In function 'ptp_ixp_init':
      drivers/net/ethernet/xscale/ptp_ixp46x.c:290:51: error: 'IXP4XX_TIMESYNC_BASE_VIRT' undeclared (first use in this function)
        290 |                 (struct ixp46x_ts_regs __iomem *) IXP4XX_TIMESYNC_BASE_VIRT;
            |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/xscale/ptp_ixp46x.c:290:51: note: each undeclared identifier is reported only once for each function it appears in
      drivers/net/ethernet/xscale/ptp_ixp46x.c: At top level:
      drivers/net/ethernet/xscale/ptp_ixp46x.c:323:1: error: data definition has no type or storage class [-Werror]
        323 | module_init(ptp_ixp_init);
      
      I have patches to complete the transition for a future release, but
      for the moment, add the missing include statements to get it to build
      again.
      
      Fixes: 09aa9aab ("soc: ixp4xx: move cpu detection to linux/soc/ixp4xx/cpu.h")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161dcc02
    • Sukadev Bhattiprolu's avatar
      ibmvnic: Remove the proper scrq flush · bb55362b
      Sukadev Bhattiprolu authored
      Commit 65d6470d ("ibmvnic: clean pending indirect buffs during reset")
      intended to remove the call to ibmvnic_tx_scrq_flush() when the
      ->resetting flag is true and was tested that way. But during the final
      rebase to net-next, the hunk got applied to a block few lines below
      (which happened to have the same diff context) and the wrong call to
      ibmvnic_tx_scrq_flush() got removed.
      
      Fix that by removing the correct ibmvnic_tx_scrq_flush() and restoring
      the one that was incorrectly removed.
      
      Fixes: 65d6470d ("ibmvnic: clean pending indirect buffs during reset")
      Reported-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarSukadev Bhattiprolu <sukadev@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb55362b
    • David S. Miller's avatar
      Merge branch 'pmtu-esp' · 3ddaed6b
      David S. Miller authored
      Vadim Fedorenko ays:
      
      ====================
      Fix PMTU for ESP-in-UDP encapsulation
      
      Bug 213669 uncovered regression in PMTU discovery for UDP-encapsulated
      routes and some incorrect usage in udp tunnel fields. This series fixes
      problems and also adds such case for selftests
      
      v3:
       - update checking logic to account SCTP use case
      v2:
       - remove refactor code that was in first patch
       - move checking logic to __udp{4,6}_lib_err_encap
       - add more tests, especially routed configuration
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ddaed6b
    • Vadim Fedorenko's avatar
      selftests: net: add ESP-in-UDP PMTU test · ece1278a
      Vadim Fedorenko authored
      The case of ESP in UDP encapsulation was not covered before. Add
      cases of local changes of MTU and difference on routed path.
      Signed-off-by: default avatarVadim Fedorenko <vfedorenko@novek.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ece1278a
    • Vadim Fedorenko's avatar
      udp: check encap socket in __udp_lib_err · 9bfce73c
      Vadim Fedorenko authored
      Commit d26796ae ("udp: check udp sock encap_type in __udp_lib_err")
      added checks for encapsulated sockets but it broke cases when there is
      no implementation of encap_err_lookup for encapsulation, i.e. ESP in
      UDP encapsulation. Fix it by calling encap_err_lookup only if socket
      implements this method otherwise treat it as legal socket.
      
      Fixes: d26796ae ("udp: check udp sock encap_type in __udp_lib_err")
      Signed-off-by: default avatarVadim Fedorenko <vfedorenko@novek.ru>
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9bfce73c
    • Xin Long's avatar
      sctp: update active_key for asoc when old key is being replaced · 58acd100
      Xin Long authored
      syzbot reported a call trace:
      
        BUG: KASAN: use-after-free in sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
        Call Trace:
         sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
         sctp_set_owner_w net/sctp/socket.c:131 [inline]
         sctp_sendmsg_to_asoc+0x152e/0x2180 net/sctp/socket.c:1865
         sctp_sendmsg+0x103b/0x1d30 net/sctp/socket.c:2027
         inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:821
         sock_sendmsg_nosec net/socket.c:703 [inline]
         sock_sendmsg+0xcf/0x120 net/socket.c:723
      
      This is an use-after-free issue caused by not updating asoc->shkey after
      it was replaced in the key list asoc->endpoint_shared_keys, and the old
      key was freed.
      
      This patch is to fix by also updating active_key for asoc when old key is
      being replaced with a new one. Note that this issue doesn't exist in
      sctp_auth_del_key_id(), as it's not allowed to delete the active_key
      from the asoc.
      
      Fixes: 1b1e0bc9 ("sctp: add refcnt support for sh_key")
      Reported-by: syzbot+b774577370208727d12b@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58acd100
    • Sayanta Pattanayak's avatar
      r8169: Avoid duplicate sysfs entry creation error · e9a72f87
      Sayanta Pattanayak authored
      When registering the MDIO bus for a r8169 device, we use the PCI
      bus/device specifier as a (seemingly) unique device identifier.
      However the very same BDF number can be used on another PCI segment,
      which makes the driver fail probing:
      
      [ 27.544136] r8169 0002:07:00.0: enabling device (0000 -> 0003)
      [ 27.559734] sysfs: cannot create duplicate filename '/class/mdio_bus/r8169-700'
      ....
      [ 27.684858] libphy: mii_bus r8169-700 failed to register
      [ 27.695602] r8169: probe of 0002:07:00.0 failed with error -22
      
      Add the segment number to the device name to make it more unique.
      
      This fixes operation on ARM N1SDP boards, with two boards connected
      together to form an SMP system, and all on-board devices showing up
      twice, just on different PCI segments. A similar issue would occur on
      large systems with many PCI slots and multiple RTL8169 NICs.
      
      Fixes: f1e911d5 ("r8169: add basic phylib support")
      Signed-off-by: default avatarSayanta Pattanayak <sayanta.pattanayak@arm.com>
      [Andre: expand commit message, use pci_domain_nr()]
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Acked-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9a72f87
  2. 20 Jul, 2021 16 commits
  3. 19 Jul, 2021 17 commits