1. 09 Oct, 2021 5 commits
    • chongjiapeng's avatar
      qed: Fix missing error code in qed_slowpath_start() · a5a14ea7
      chongjiapeng authored
      The error code is missing in this code scenario, add the error code
      '-EINVAL' to the return value 'rc'.
      
      Eliminate the follow smatch warning:
      
      drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start()
      warn: missing error code 'rc'.
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Fixes: d51e4af5 ("qed: aRFS infrastructure support")
      Signed-off-by: default avatarchongjiapeng <jiapeng.chong@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5a14ea7
    • Vladimir Oltean's avatar
      net: dsa: hold rtnl_lock in dsa_switch_setup_tag_protocol · 1951b3f1
      Vladimir Oltean authored
      It was a documented fact that ds->ops->change_tag_protocol() offered
      rtnetlink mutex protection to the switch driver, since there was an
      ASSERT_RTNL right before the call in dsa_switch_change_tag_proto()
      (initiated from sysfs).
      
      The blamed commit introduced another call path for
      ds->ops->change_tag_protocol() which does not hold the rtnl_mutex.
      This is:
      
      dsa_tree_setup
      -> dsa_tree_setup_switches
         -> dsa_switch_setup
            -> dsa_switch_setup_tag_protocol
               -> ds->ops->change_tag_protocol()
         -> dsa_port_setup
            -> dsa_slave_create
               -> register_netdevice(slave_dev)
      -> dsa_tree_setup_master
         -> dsa_master_setup
            -> dev->dsa_ptr = cpu_dp
      
      The reason why the rtnl_mutex is held in the sysfs call path is to
      ensure that, once the master and all the DSA interfaces are down (which
      is required so that no packets flow), they remain down during the
      tagging protocol change.
      
      The above calling order illustrates the fact that it should not be risky
      to change the initial tagging protocol to the one specified in the
      device tree at the given time:
      
      - packets cannot enter the dsa_switch_rcv() packet type handler since
        netdev_uses_dsa() for the master will not yet return true, since
        dev->dsa_ptr has not yet been populated
      
      - packets cannot enter the dsa_slave_xmit() function because no DSA
        interface has yet been registered
      
      So from the DSA core's perspective, holding the rtnl_mutex is indeed not
      necessary.
      
      Yet, drivers may need to do things which need rtnl_mutex protection. For
      example:
      
      felix_set_tag_protocol
      -> felix_setup_tag_8021q
         -> dsa_tag_8021q_register
            -> dsa_tag_8021q_setup
               -> dsa_tag_8021q_port_setup
                  -> vlan_vid_add
                     -> ASSERT_RTNL
      
      These drivers do not really have a choice to take the rtnl_mutex
      themselves, since in the sysfs case, the rtnl_mutex is already held.
      
      Fixes: deff7107 ("net: dsa: Allow default tag protocol to be overridden from DT")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1951b3f1
    • Zheyu Ma's avatar
      isdn: mISDN: Fix sleeping function called from invalid context · 6510e80a
      Zheyu Ma authored
      The driver can call card->isac.release() function from an atomic
      context.
      
      Fix this by calling this function after releasing the lock.
      
      The following log reveals it:
      
      [   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
      [   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
      [   44.169574 ] INFO: lockdep is turned off.
      [   44.169899 ] irq event stamp: 0
      [   44.170160 ] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
      [   44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
      [   44.171240 ] softirqs last  enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
      [   44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
      [   44.172318 ] Preemption disabled at:
      [   44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
      [   44.174441 ] Call Trace:
      [   44.174630 ]  dump_stack_lvl+0xa8/0xd1
      [   44.174912 ]  dump_stack+0x15/0x17
      [   44.175166 ]  ___might_sleep+0x3a2/0x510
      [   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
      [   44.175791 ]  __might_sleep+0x82/0xe0
      [   44.176063 ]  ? start_flush_work+0x20/0x7b0
      [   44.176375 ]  start_flush_work+0x33/0x7b0
      [   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
      [   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
      [   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
      [   44.177711 ]  __flush_work+0x11a/0x1a0
      [   44.177991 ]  ? flush_work+0x20/0x20
      [   44.178257 ]  ? lock_release+0x13c/0x8f0
      [   44.178550 ]  ? __kasan_check_write+0x14/0x20
      [   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
      [   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
      [   44.179530 ]  ? __kasan_check_read+0x11/0x20
      [   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
      [   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
      [   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
      [   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
      [   44.181189 ]  ? kfree+0x13e/0x290
      [   44.181438 ]  flush_work+0x17/0x20
      [   44.181695 ]  mISDN_freedchannel+0xe8/0x100
      [   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
      [   44.182366 ]  nj_release+0xf6/0x500 [netjet]
      [   44.182685 ]  nj_remove+0x48/0x70 [netjet]
      [   44.182989 ]  pci_device_remove+0xa9/0x250
      Signed-off-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6510e80a
    • Shannon Nelson's avatar
      ionic: don't remove netdev->dev_addr when syncing uc list · 5c976a56
      Shannon Nelson authored
      Bridging, and possibly other upper stack gizmos, adds the
      lower device's netdev->dev_addr to its own uc list, and
      then requests it be deleted when the upper bridge device is
      removed.  This delete request also happens with the bridging
      vlan_filtering is enabled and then disabled.
      
      Bonding has a similar behavior with the uc list, but since it
      also uses set_mac to manage netdev->dev_addr, it doesn't have
      the same the failure case.
      
      Because we store our netdev->dev_addr in our uc list, we need
      to ignore the delete request from dev_uc_sync so as to not
      lose the address and all hope of communicating.  Note that
      ndo_set_mac_address is expressly changing netdev->dev_addr,
      so no limitation is set there.
      
      Fixes: 2a654540 ("ionic: Add Rx filter and rx_mode ndo support")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c976a56
    • Haiyang Zhang's avatar
      net: mana: Fix error handling in mana_create_rxq() · be049936
      Haiyang Zhang authored
      Fix error handling in mana_create_rxq() when
      cq->gdma_id >= gc->max_num_cqs.
      
      Fixes: ca9c54d2 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Link: https://lore.kernel.org/r/1633698691-31721-1-git-send-email-haiyangz@microsoft.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      be049936
  2. 08 Oct, 2021 15 commits
    • Xiaolong Huang's avatar
      isdn: cpai: check ctr->cnr to avoid array index out of bound · 1f3e2e97
      Xiaolong Huang authored
      The cmtp_add_connection() would add a cmtp session to a controller
      and run a kernel thread to process cmtp.
      
      	__module_get(THIS_MODULE);
      	session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d",
      								session->num);
      
      During this process, the kernel thread would call detach_capi_ctr()
      to detach a register controller. if the controller
      was not attached yet, detach_capi_ctr() would
      trigger an array-index-out-bounds bug.
      
      [   46.866069][ T6479] UBSAN: array-index-out-of-bounds in
      drivers/isdn/capi/kcapi.c:483:21
      [   46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]'
      [   46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted
      5.15.0-rc2+ #8
      [   46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX,
      1996), BIOS 1.14.0-2 04/01/2014
      [   46.870107][ T6479] Call Trace:
      [   46.870473][ T6479]  dump_stack_lvl+0x57/0x7d
      [   46.870974][ T6479]  ubsan_epilogue+0x5/0x40
      [   46.871458][ T6479]  __ubsan_handle_out_of_bounds.cold+0x43/0x48
      [   46.872135][ T6479]  detach_capi_ctr+0x64/0xc0
      [   46.872639][ T6479]  cmtp_session+0x5c8/0x5d0
      [   46.873131][ T6479]  ? __init_waitqueue_head+0x60/0x60
      [   46.873712][ T6479]  ? cmtp_add_msgpart+0x120/0x120
      [   46.874256][ T6479]  kthread+0x147/0x170
      [   46.874709][ T6479]  ? set_kthread_struct+0x40/0x40
      [   46.875248][ T6479]  ret_from_fork+0x1f/0x30
      [   46.875773][ T6479]
      Signed-off-by: default avatarXiaolong Huang <butterflyhuangxx@gmail.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20211008065830.305057-1-butterflyhuangxx@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1f3e2e97
    • Sebastian Andrzej Siewior's avatar
      mqprio: Correct stats in mqprio_dump_class_stats(). · 14132690
      Sebastian Andrzej Siewior authored
      Introduction of lockless subqueues broke the class statistics.
      Before the change stats were accumulated in `bstats' and `qstats'
      on the stack which was then copied to struct gnet_dump.
      
      After the change the `bstats' and `qstats' are initialized to 0
      and never updated, yet still fed to gnet_dump. The code updates
      the global qdisc->cpu_bstats and qdisc->cpu_qstats instead,
      clobbering them. Most likely a copy-paste error from the code in
      mqprio_dump().
      
      __gnet_stats_copy_basic() and __gnet_stats_copy_queue() accumulate
      the values for per-CPU case but for global stats they overwrite
      the value, so only stats from the last loop iteration / tc end up
      in sch->[bq]stats.
      
      Use the on-stack [bq]stats variables again and add the stats manually
      in the global case.
      
      Fixes: ce679e8d ("net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mqprio")
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      https://lore.kernel.org/all/20211007175000.2334713-2-bigeasy@linutronix.de/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      14132690
    • Jakub Kicinski's avatar
      Merge branch 'dsa-bridge-tx-forwarding-offload-fixes-part-1' · bccf56c4
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      DSA bridge TX forwarding offload fixes - part 1
      
      This is part 1 of a series of fixes to the bridge TX forwarding offload
      feature introduced for v5.15. Sadly, the other fixes are so intrusive
      that they cannot be reasonably be sent to the "net" tree, as they also
      include API changes. So they are left as part 2 for net-next.
      ====================
      
      Link: https://lore.kernel.org/r/20211007164711.2897238-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bccf56c4
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports · 5bded825
      Vladimir Oltean authored
      Similar to commit 6087175b ("net: dsa: mt7530: use independent VLAN
      learning on VLAN-unaware bridges"), software forwarding between an
      unoffloaded LAG port (a bonding interface with an unsupported policy)
      and a mv88e6xxx user port directly under a bridge is broken.
      
      We adopt the same strategy, which is to make the standalone ports not
      find any ATU entry learned on a bridge port.
      
      Theory: the mv88e6xxx ATU is looked up by FID and MAC address. There are
      as many FIDs as VIDs (4096). The FID is derived from the VID when
      possible (the VTU maps a VID to a FID), with a fallback to the port
      based default FID value when not (802.1Q Mode is disabled on the port,
      or the classified VID isn't present in the VTU).
      
      The mv88e6xxx driver makes the following use of FIDs and VIDs:
      
      - the port's DefaultVID (to which untagged & pvid-tagged packets get
        classified) is 0 and is absent from the VTU, so this kind of packets is
        processed in FID 0, the default FID assigned by mv88e6xxx_setup_port.
      
      - every time a bridge VLAN is created, mv88e6xxx_port_vlan_join() ->
        mv88e6xxx_atu_new() associates a FID with that VID which increases
        linearly starting from 1. Like this:
      
        bridge vlan add dev lan0 vid 100 # FID 1
        bridge vlan add dev lan1 vid 100 # still FID 1
        bridge vlan add dev lan2 vid 1024 # FID 2
      
      The FID allocation made by the driver is sub-optimal for the following
      reasons:
      
      (a) A standalone port has a DefaultPVID of 0 and a default FID of 0 too.
          A VLAN-unaware bridged port has a DefaultPVID of 0 and a default FID
          of 0 too. The difference is that the bridged ports may learn ATU
          entries, while the standalone port has the requirement that it must
          not, and must not find them either. Standalone ports must not use
          the same FID as ports belonging to a bridge. All standalone ports
          can use the same FID, since the ATU will never have an entry in
          that FID.
      
      (b) Multiple VLAN-unaware bridges will all use a DefaultPVID of 0 and a
          default FID of 0 on all their ports. The FDBs will not be isolated
          between these bridges. Every VLAN-unaware bridge must use the same
          FID on all its ports, different from the FID of other bridge ports.
      
      (c) Each bridge VLAN uses a unique FID which is useful for Independent
          VLAN Learning, but the same VLAN ID on multiple VLAN-aware bridges
          will result in the same FID being used by mv88e6xxx_atu_new().
          The correct behavior is for VLAN 1 in br0 to have a different FID
          compared to VLAN 1 in br1.
      
      This patch cannot fix all the above. Traditionally the DSA framework did
      not care about this, and the reality is that DSA core involvement is
      needed for the aforementioned issues to be solved. The only thing we can
      solve here is an issue which does not require API changes, and that is
      issue (a), aka use a different FID for standalone ports vs ports under
      VLAN-unaware bridges.
      
      The first step is deciding what VID and FID to use for standalone ports,
      and what VID and FID for bridged ports. The 0/0 pair for standalone
      ports is what they used up till now, let's keep using that. For bridged
      ports, there are 2 cases:
      
      - VLAN-aware ports will never end up using the port default FID, because
        packets will always be classified to a VID in the VTU or dropped
        otherwise. The FID is the one associated with the VID in the VTU.
      
      - On VLAN-unaware ports, we _could_ leave their DefaultVID (pvid) at
        zero (just as in the case of standalone ports), and just change the
        port's default FID from 0 to a different number (say 1).
      
      However, Tobias points out that there is one more requirement to cater to:
      cross-chip bridging. The Marvell DSA header does not carry the FID in
      it, only the VID. So once a packet crosses a DSA link, if it has a VID
      of zero it will get classified to the default FID of that cascade port.
      Relying on a port default FID for upstream cascade ports results in
      contradictions: a default FID of 0 breaks ATU isolation of bridged ports
      on the downstream switch, a default FID of 1 breaks standalone ports on
      the downstream switch.
      
      So not only must standalone ports have different FIDs compared to
      bridged ports, they must also have different DefaultVID values.
      IEEE 802.1Q defines two reserved VID values: 0 and 4095. So we simply
      choose 4095 as the DefaultVID of ports belonging to VLAN-unaware
      bridges, and VID 4095 maps to FID 1.
      
      For the xmit operation to look up the same ATU database, we need to put
      VID 4095 in DSA tags sent to ports belonging to VLAN-unaware bridges
      too. All shared ports are configured to map this VID to the bridging
      FID, because they are members of that VLAN in the VTU. Shared ports
      don't need to have 802.1QMode enabled in any way, they always parse the
      VID from the DSA header, they don't need to look at the 802.1Q header.
      
      We install VID 4095 to the VTU in mv88e6xxx_setup_port(), with the
      mention that mv88e6xxx_vtu_setup() which was located right below that
      call was flushing the VTU so those entries wouldn't be preserved.
      So we need to relocate the VTU flushing prior to the port initialization
      during ->setup(). Also note that this is why it is safe to assume that
      VID 4095 will get associated with FID 1: the user ports haven't been
      created, so there is no avenue for the user to create a bridge VLAN
      which could otherwise race with the creation of another FID which would
      otherwise use up the non-reserved FID value of 1.
      
      [ Currently mv88e6xxx_port_vlan_join() doesn't have the option of
        specifying a preferred FID, it always calls mv88e6xxx_atu_new(). ]
      
      mv88e6xxx_port_db_load_purge() is the function to access the ATU for
      FDB/MDB entries, and it used to determine the FID to use for
      VLAN-unaware FDB entries (VID=0) using mv88e6xxx_port_get_fid().
      But the driver only called mv88e6xxx_port_set_fid() once, during probe,
      so no surprises, the port FID was always 0, the call to get_fid() was
      redundant. As much as I would have wanted to not touch that code, the
      logic is broken when we add a new FID which is not the port-based
      default. Now the port-based default FID only corresponds to standalone
      ports, and FDB/MDB entries belong to the bridging service. So while in
      the future, when the DSA API will support FDB isolation, we will have to
      figure out the FID based on the bridge number, for now there's a single
      bridging FID, so hardcode that.
      
      Lastly, the tagger needs to check, when it is transmitting a VLAN
      untagged skb, whether it is sending it towards a bridged or a standalone
      port. When we see it is bridged we assume the bridge is VLAN-unaware.
      Not because it cannot be VLAN-aware but:
      
      - if we are transmitting from a VLAN-aware bridge we are likely doing so
        using TX forwarding offload. That code path guarantees that skbs have
        a vlan hwaccel tag in them, so we would not enter the "else" branch
        of the "if (skb->protocol == htons(ETH_P_8021Q))" condition.
      
      - if we are transmitting on behalf of a VLAN-aware bridge but with no TX
        forwarding offload (no PVT support, out of space in the PVT, whatever),
        we would indeed be transmitting with VLAN 4095 instead of the bridge
        device's pvid. However we would be injecting a "From CPU" frame, and
        the switch won't learn from that - it only learns from "Forward" frames.
        So it is inconsequential for address learning. And VLAN 4095 is
        absolutely enough for the frame to exit the switch, since we never
        remove that VLAN from any port.
      
      Fixes: 57e661aa ("net: dsa: mv88e6xxx: Link aggregation support")
      Reported-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5bded825
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware · 8b6836d8
      Vladimir Oltean authored
      The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679
      ("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
      some issues with VLAN and decided the best way to deal with them was to
      make the DSA core ignore VLANs added by the bridge while VLAN awareness
      is turned off. Those issues were never explained, just presented as
      "at least one corner case".
      
      That approach had problems of its own, presented by
      commit 54a0ed0d ("net: dsa: provide an option for drivers to always
      receive bridge VLANs") for the DSA core, followed by
      commit 1fb74191 ("net: dsa: mv88e6xxx: fix vlan setup") which
      applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
      particular.
      
      We still don't know what corner case Andrew saw when he wrote
      commit 2ea7a679 ("net: dsa: Don't add vlans when vlan filtering is
      disabled"), but Tobias now reports that when we use TX forwarding
      offload, pinging an external station from the bridge device is broken if
      the front-facing DSA user port has flooding turned off. The full
      description is in the link below, but for short, when a mv88e6xxx port
      is under a VLAN-unaware bridge, it inherits that bridge's pvid.
      So packets ingressing a user port will be classified to e.g. VID 1
      (assuming that value for the bridge_default_pvid), whereas when
      tag_dsa.c xmits towards a user port, it always sends packets using a VID
      of 0 if that port is standalone or under a VLAN-unaware bridge - or at
      least it did so prior to commit d82f8ab0 ("net: dsa: tag_dsa:
      offload the bridge forwarding process").
      
      In any case, when there is a conversation between the CPU and a station
      connected to a user port, the station's MAC address is learned in VID 1
      but the CPU tries to transmit through VID 0. The packets reach the
      intended station, but via flooding and not by virtue of matching the
      existing ATU entry.
      
      DSA has established (and enforced in other drivers: sja1105, felix,
      mt7530) that a VLAN-unaware port should use a private pvid, and not
      inherit the one from the bridge. The bridge's pvid should only be
      inherited when that bridge is VLAN-aware, so all state transitions need
      to be handled. On the other hand, all bridge VLANs should sit in the VTU
      starting with the moment when the bridge offloads them via switchdev,
      they are just not used.
      
      This solves the problem that Tobias sees because packets ingressing on
      VLAN-unaware user ports now get classified to VID 0, which is also the
      VID used by tag_dsa.c on xmit.
      
      Fixes: d82f8ab0 ("net: dsa: tag_dsa: offload the bridge forwarding process")
      Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503Reported-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8b6836d8
    • Vladimir Oltean's avatar
      net: dsa: tag_dsa: send packets with TX fwd offload from VLAN-unaware bridges using VID 0 · c7709a02
      Vladimir Oltean authored
      The present code is structured this way due to an incomplete thought
      process. In Documentation/networking/switchdev.rst we document that if a
      bridge is VLAN-unaware, then the presence or lack of a pvid on a bridge
      port (or on the bridge itself, for that matter) should not affect the
      ability to receive and transmit tagged or untagged packets.
      
      If the bridge on behalf of which we are sending this packet is
      VLAN-aware, then the TX forwarding offload API ensures that the skb will
      be VLAN-tagged (if the packet was sent by user space as untagged, it
      will get transmitted town to the driver as tagged with the bridge
      device's pvid). But if the bridge is VLAN-unaware, it may or may not be
      VLAN-tagged. In fact the logic to insert the bridge's PVID came from the
      idea that we should emulate what is being done in the VLAN-aware case.
      But we shouldn't.
      
      It appears that injecting packets using a VLAN ID of 0 serves the
      purpose of forwarding the packets to the egress port with no VLAN tag
      added or stripped by the hardware, and no filtering being performed.
      So we can simply remove the superfluous logic.
      
      One reason why this logic is broken is that when CONFIG_BRIDGE_VLAN_FILTERING=n,
      we call br_vlan_get_pvid_rcu() but that returns an error and we do error
      out, dropping all packets on xmit. Not really smart. This is also an
      issue when the user deletes the bridge pvid:
      
      $ bridge vlan del dev br0 vid 1 self
      
      As mentioned, in both cases, packets should still flow freely, and they
      do just that on any net device where the bridge is not offloaded, but on
      mv88e6xxx they don't.
      
      Fixes: d82f8ab0 ("net: dsa: tag_dsa: offload the bridge forwarding process")
      Reported-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003155141.2241314-1-andrew@lunn.ch/
      Link: https://patchwork.kernel.org/project/netdevbpf/patch/20210928233708.1246774-1-vladimir.oltean@nxp.com/Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c7709a02
    • Vladimir Oltean's avatar
      net: dsa: fix bridge_num not getting cleared after ports leaving the bridge · 1bec0f05
      Vladimir Oltean authored
      The dp->bridge_num is zero-based, with -1 being the encoding for an
      invalid value. But dsa_bridge_num_put used to check for an invalid value
      by comparing bridge_num with 0, which is of course incorrect.
      
      The result is that the bridge_num will never get cleared by
      dsa_bridge_num_put, and further port joins to other bridges will get a
      bridge_num larger than the previous one, and once all the available
      bridges with TX forwarding offload supported by the hardware get
      exhausted, the TX forwarding offload feature is simply disabled.
      
      In the case of sja1105, 7 iterations of the loop below are enough to
      exhaust the TX forwarding offload bits, and further bridge joins operate
      without that feature.
      
      ip link add br0 type bridge vlan_filtering 1
      
      while :; do
              ip link set sw0p2 master br0 && sleep 1
              ip link set sw0p2 nomaster && sleep 1
      done
      
      This issue is enough of an indication that having the dp->bridge_num
      invalid encoding be a negative number is prone to bugs, so this will be
      changed to a one-based value, with the dp->bridge_num of zero being the
      indication of no bridge. However, that is material for net-next.
      
      Fixes: f5e165e7 ("net: dsa: track unique bridge numbers across all DSA switch trees")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1bec0f05
    • Lin Ma's avatar
      nfc: nci: fix the UAF of rf_conn_info object · 1b1499a8
      Lin Ma authored
      The nci_core_conn_close_rsp_packet() function will release the conn_info
      with given conn_id. However, it needs to set the rf_conn_info to NULL to
      prevent other routines like nci_rf_intf_activated_ntf_packet() to trigger
      the UAF.
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b1499a8
    • Karsten Graul's avatar
      net/smc: improved fix wait on already cleared link · 95f7f3e7
      Karsten Graul authored
      Commit 8f3d65c1 ("net/smc: fix wait on already cleared link")
      introduced link refcounting to avoid waits on already cleared links.
      This patch extents and improves the refcounting to cover all
      remaining possible cases for this kind of error situation.
      
      Fixes: 15e1b99a ("net/smc: no WR buffer wait for terminating link group")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95f7f3e7
    • David S. Miller's avatar
      Merge branch 'stmmac-regression-fix' · 097657c9
      David S. Miller authored
      Merge branch 'stmmac-regression-fix'
      
      Herve Codina says:
      
      ====================
      net: stmmac: fix regression on SPEAr3xx SOC
      
      The ethernet driver used on old SPEAr3xx soc was previously supported on old
      kernel. Some regressions were introduced during the different updates leading
      to a broken driver for this soc.
      
      This series fixes these regressions and brings back ethernet on SPEAr3xx.
      Tested on a SPEAr320 board.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      097657c9
    • Herve Codina's avatar
      ARM: dts: spear3xx: Fix gmac node · 6636fec2
      Herve Codina authored
      On SPEAr3xx, ethernet driver is not compatible with the SPEAr600
      one.
      Indeed, SPEAr3xx uses an earlier version of this IP (v3.40) and
      needs some driver tuning compare to SPEAr600.
      
      The v3.40 IP support was added to stmmac driver and this patch
      fixes this issue and use the correct compatible string for
      SPEAr3xx
      Signed-off-by: default avatarHerve Codina <herve.codina@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6636fec2
    • Herve Codina's avatar
      net: stmmac: add support for dwmac 3.40a · 9cb1d19f
      Herve Codina authored
      dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc.
      Signed-off-by: default avatarHerve Codina <herve.codina@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cb1d19f
    • Herve Codina's avatar
      dt-bindings: net: snps,dwmac: add dwmac 3.40a IP version · 3781b6ad
      Herve Codina authored
      dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc.
      Signed-off-by: default avatarHerve Codina <herve.codina@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3781b6ad
    • Herve Codina's avatar
      net: stmmac: fix get_hw_feature() on old hardware · 075da584
      Herve Codina authored
      Some old IPs do not provide the hardware feature register.
      On these IPs, this register is read 0x00000000.
      
      In old driver version, this feature was handled but a regression came
      with the commit f10a6a35 ("stmmac: rework get_hw_feature function").
      Indeed, this commit removes the return value in dma->get_hw_feature().
      This return value was used to indicate the validity of retrieved
      information and used later on in stmmac_hw_init() to override
      priv->plat data if this hardware feature were valid.
      
      This patch restores the return code in ->get_hw_feature() in order
      to indicate the hardware feature validity and override priv->plat
      data only if this hardware feature is valid.
      
      Fixes: f10a6a35 ("stmmac: rework get_hw_feature function")
      Signed-off-by: default avatarHerve Codina <herve.codina@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      075da584
    • Paolo Abeni's avatar
      mptcp: fix possible stall on recvmsg() · 612f71d7
      Paolo Abeni authored
      recvmsg() can enter an infinite loop if the caller provides the
      MSG_WAITALL, the data present in the receive queue is not sufficient to
      fulfill the request, and no more data is received by the peer.
      
      When the above happens, mptcp_wait_data() will always return with
      no wait, as the MPTCP_DATA_READY flag checked by such function is
      set and never cleared in such code path.
      
      Leveraging the above syzbot was able to trigger an RCU stall:
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1
              (t=10500 jiffies g=13089 q=109)
      rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
      rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
      rcu: RCU grace-period kthread stack dump:
      task:rcu_preempt     state:R  running task     stack:28696 pid:   14 ppid:     2 flags:0x00004000
      Call Trace:
       context_switch kernel/sched/core.c:4955 [inline]
       __schedule+0x940/0x26f0 kernel/sched/core.c:6236
       schedule+0xd3/0x270 kernel/sched/core.c:6315
       schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881
       rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955
       rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128
       kthread+0x405/0x4f0 kernel/kthread.c:327
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
      rcu: Stack dump where RCU GP kthread last ran:
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline]
      RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline]
      RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline]
      RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline]
      RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
      RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189
      Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00
      RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283
      RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a
      RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870
      RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877
      R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000
      R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000
      FS:  0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
      S:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
       test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline]
       mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016
       release_sock+0xb4/0x1b0 net/core/sock.c:3204
       mptcp_wait_data net/mptcp/protocol.c:1770 [inline]
       mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080
       inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659
       sock_recvmsg_nosec net/socket.c:944 [inline]
       ____sys_recvmsg+0x527/0x600 net/socket.c:2626
       ___sys_recvmsg+0x127/0x200 net/socket.c:2670
       do_recvmmsg+0x24d/0x6d0 net/socket.c:2764
       __sys_recvmmsg net/socket.c:2843 [inline]
       __do_sys_recvmmsg net/socket.c:2866 [inline]
       __se_sys_recvmmsg net/socket.c:2859 [inline]
       __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7fc200d2dc39
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffc5758e5a8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc200d2dc39
      RDX: 0000000000000002 RSI: 00000000200017c0 RDI: 0000000000000003
      RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000f0b5ff
      R10: 0000000000000100 R11: 0000000000000246 R12: 0000000000000003
      R13: 00007ffc5758e5d0 R14: 00007ffc5758e5c0 R15: 0000000000000003
      
      Fix the issue by replacing the MPTCP_DATA_READY bit with direct
      inspection of the msk receive queue.
      
      Reported-and-tested-by: syzbot+3360da629681aa0d22fe@syzkaller.appspotmail.com
      Fixes: 7a6a6cbc ("mptcp: recvmsg() can drain data from multiple subflow")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      612f71d7
  3. 07 Oct, 2021 16 commits
    • Linus Torvalds's avatar
      Merge tag 'nfsd-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux · 1da38549
      Linus Torvalds authored
      Pull nfsd fixes from Chuck Lever:
       "Bug fixes for NFSD error handling paths"
      
      * tag 'nfsd-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
        NFSD: Keep existing listeners on portlist error
        SUNRPC: fix sign error causing rpcsec_gss drops
        nfsd: Fix a warning for nfsd_file_close_inode
        nfsd4: Handle the NFSv4 READDIR 'dircount' hint being zero
        nfsd: fix error handling of register_pernet_subsys() in init_nfsd()
      1da38549
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc · 3e899c72
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "This is a larger than normal update for Arm SoC specific code, most of
        it in device trees, but also drivers and the omap and at91/sama7
        platforms:
      
         - There are four new entries to the MAINTAINERS file: Sven Peter and
           Alyssa Rosenzweig for Apple M1, Romain Perier for Mstar/sigmastar,
           and Vignesh Raghavendra for TI K3
      
         - Build fixes to address randconfig warnings in sharpsl, dove, omap1,
           and qcom platforms as well as the scmi and op-tee subsystems
      
         - Regression fixes for missing CONFIG_FB and other options for
           several defconfigs
      
         - Several bug fixes for the newly added Microchip SAMA7 platform,
           mostly regarding power management
      
         - Missing SMP barriers to protect accesses to SCMI virtio device
      
         - Regression fixes for TI OMAP, including a boot-time hang on am335x.
      
         - Lots of bug fixes for NXP i.MX, mostly addressing incorrect
           settings in devicetree files, and one revert for broken suspend.
      
         - Fixes for ARM Juno/Vexpress devicetree files, addressing a couple
           of schema warnings.
      
         - Regression fixes for qualcomm SoC specific drivers and devicetree
           files, reverting an mdt_loader change and at least pastially
           reverting some of the 5.15 DTS changes, plus some minor bugfixes"
      
      * tag 'armsoc-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (64 commits)
        MAINTAINERS: Add Sven Peter as ARM/APPLE MACHINE maintainer
        MAINTAINERS: Add Alyssa Rosenzweig as M1 reviewer
        firmware: arm_scmi: Add proper barriers to scmi virtio device
        firmware: arm_scmi: Simplify spinlocks in virtio transport
        ARM: dts: omap3430-sdp: Fix NAND device node
        bus: ti-sysc: Use CLKDM_NOAUTO for dra7 dcan1 for errata i893
        ARM: sharpsl_param: work around -Wstringop-overread warning
        ARM: defconfig: gemini: Restore framebuffer
        ARM: dove: mark 'putc' as inline
        ARM: omap1: move omap15xx local bus handling to usb.c
        MAINTAINERS: Add Vignesh to TI K3 platform maintainership
        arm64: dts: imx8m*-venice-gw7902: fix M2_RST# gpio
        ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequence
        arm64: dts: ls1028a: fix eSDHC2 node
        arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2
        ARM: dts: at91: sama7g5ek: to not touch slew-rate for SDMMC pins
        ARM: dts: at91: sama7g5ek: use proper slew-rate settings for GMACs
        ARM: at91: pm: preload base address of controllers in tlb
        ARM: at91: pm: group constants and addresses loading
        ARM: dts: at91: sama7g5ek: add suspend voltage for ddr3l rail
        ...
      3e899c72
    • Arnd Bergmann's avatar
      Merge tag 'asahi-soc-fixes-5.15' of https://github.com/AsahiLinux/linux into arm/fixes · 897c2e74
      Arnd Bergmann authored
      Apple SoC fixes for 5.15; just two MAINTAINERS updates.
      
      - MAINTAINERS: Add Sven Peter as ARM/APPLE MACHINE maintainer
      - MAINTAINERS: Add Alyssa Rosenzweig as M1 reviewer
      
      * tag 'asahi-soc-fixes-5.15' of https://github.com/AsahiLinux/linux:
        MAINTAINERS: Add Sven Peter as ARM/APPLE MACHINE maintainer
        MAINTAINERS: Add Alyssa Rosenzweig as M1 reviewer
      
      Link: https://lore.kernel.org/r/a50a9015-0e62-c451-4d0d-668233b35b85@marcan.stSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      897c2e74
    • Arnd Bergmann's avatar
      Merge tag 'scmi-fixes-5.15' of... · 6aaa8434
      Arnd Bergmann authored
      Merge tag 'scmi-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
      
      SCMI fixes for v5.15
      
      A few fixes addressing:
      - Kconfig dependency between VIRTIO and ARM_SCMI_PROTOCOL
      - Link-time error with __exit annotation for virtio_scmi_exit
      - Unnecessary nested irqsave/irqrestore spinlocks in virtio transport
      - Missing SMP barriers to protect accesses to SCMI virtio device
      
      * tag 'scmi-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
        firmware: arm_scmi: Add proper barriers to scmi virtio device
        firmware: arm_scmi: Simplify spinlocks in virtio transport
        firmware: arm_scmi: Remove __exit annotation
        firmware: arm_scmi: Fix virtio transport Kconfig dependency
      
      Link: https://lore.kernel.org/r/20211007102822.27886-1-sudeep.holla@arm.comSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      6aaa8434
    • Arnd Bergmann's avatar
      Merge tag 'omap-for-v5.15/fixes-rc4' of... · 3c7f58b3
      Arnd Bergmann authored
      Merge tag 'omap-for-v5.15/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
      
      Fixes for omaps for v5.15
      
      Few regression fixes for omaps for the v5.15-rc cycle. There is a fix
      for boot time hangs that can happen on some am335x devices that started
      when the pruss devicetree nodes were added. The other fixes are less
      critical:
      
      - Fix compiler warning for sysc_init_soc() that got recently introduced
      
      - Fix external abort for am335x pruss as otherwise some am335x will hang
      
      - Use CLKDM_NOAUTO quirk also for dra7 dcan1
      
      - Fix older NAND device node regression for omap3-sdp
      
      * tag 'omap-for-v5.15/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: dts: omap3430-sdp: Fix NAND device node
        bus: ti-sysc: Use CLKDM_NOAUTO for dra7 dcan1 for errata i893
        soc: ti: omap-prm: Fix external abort for am335x pruss
        bus: ti-sysc: Add break in switch statement in sysc_init_soc()
      
      Link: https://lore.kernel.org/r/pull-1633609552-789682@atomide.comSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      3c7f58b3
    • Linus Torvalds's avatar
      Merge tag 'misc-fixes-20211007' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 7041503d
      Linus Torvalds authored
      Pull netfslib, cachefiles and afs fixes from David Howells:
      
       - Fix another couple of oopses in cachefiles tracing stemming from the
         possibility of passing in a NULL object pointer
      
       - Fix netfs_clear_unread() to set READ on the iov_iter so that source
         it is passed to doesn't do the wrong thing (some drivers look at the
         flag on iov_iter rather than other available information to determine
         the direction)
      
       - Fix afs_launder_page() to write back at the correct file position on
         the server so as not to corrupt data
      
      * tag 'misc-fixes-20211007' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
        afs: Fix afs_launder_page() to set correct start file position
        netfs: Fix READ/WRITE confusion when calling iov_iter_xarray()
        cachefiles: Fix oops with cachefiles_cull() due to NULL object
      7041503d
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v5.15-2021-10-07' of... · 14df9235
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v5.15-2021-10-07' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - Fix plugin static linking with libopencsd on ARM and ARM64
      
       - Add missing -lstdc++ when linking with libopencsd
      
       - Add missing topdown metrics events to 'perf test attr'
      
       - Plug leak sys_event_tables list after processing JSON vendor events
         entries
      
       - Sync sound/asound.h copy with the kernel sources
      
      * tag 'perf-tools-fixes-for-v5.15-2021-10-07' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        perf tests attr: Add missing topdown metrics events
        tools include UAPI: Sync sound/asound.h copy with the kernel sources
        perf build: Fix plugin static linking with libopencsd on ARM and ARM64
        perf build: Add missing -lstdc++ when linking with libopencsd
        perf jevents: Free the sys_event_tables list after processing entries
      14df9235
    • Linus Torvalds's avatar
      Merge tag 'net-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 4a16df54
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from xfrm, bpf, netfilter, and wireless.
      
        Current release - regressions:
      
         - xfrm: fix XFRM_MSG_MAPPING ABI breakage caused by inserting a new
           value in the middle of an enum
      
         - unix: fix an issue in unix_shutdown causing the other end
           read/write failures
      
         - phy: mdio: fix memory leak
      
        Current release - new code bugs:
      
         - mlx5e: improve MQPRIO resiliency against bad configs
      
        Previous releases - regressions:
      
         - bpf: fix integer overflow leading to OOB access in map element
           pre-allocation
      
         - stmmac: dwmac-rk: fix ethernet on rk3399 based devices
      
         - netfilter: conntrack: fix boot failure with
           nf_conntrack.enable_hooks=1
      
         - brcmfmac: revert using ISO3166 country code and 0 rev as fallback
      
         - i40e: fix freeing of uninitialized misc IRQ vector
      
         - iavf: fix double unlock of crit_lock
      
        Previous releases - always broken:
      
         - bpf, arm: fix register clobbering in div/mod implementation
      
         - netfilter: nf_tables: correct issues in netlink rule change event
           notifications
      
         - dsa: tag_dsa: fix mask for trunked packets
      
         - usb: r8152: don't resubmit rx immediately to avoid soft lockup on
           device unplug
      
         - i40e: fix endless loop under rtnl if FW fails to correctly respond
           to capability query
      
         - mlx5e: fix rx checksum offload coexistence with ipsec offload
      
         - mlx5: force round second at 1PPS out start time and allow it only
           in supported clock modes
      
         - phy: pcs: xpcs: fix incorrect CL37 AN sequence, EEE disable
           sequence
      
        Misc:
      
         - xfrm: slightly rejig the new policy uAPI to make it less cryptic"
      
      * tag 'net-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (66 commits)
        net: prefer socket bound to interface when not in VRF
        iavf: fix double unlock of crit_lock
        i40e: Fix freeing of uninitialized misc IRQ vector
        i40e: fix endless loop under rtnl
        dt-bindings: net: dsa: marvell: fix compatible in example
        ionic: move filter sync_needed bit set
        gve: report 64bit tx_bytes counter from gve_handle_report_stats()
        gve: fix gve_get_stats()
        rtnetlink: fix if_nlmsg_stats_size() under estimation
        gve: Properly handle errors in gve_assign_qpl
        gve: Avoid freeing NULL pointer
        gve: Correct available tx qpl check
        unix: Fix an issue in unix_shutdown causing the other end read/write failures
        net: stmmac: trigger PCS EEE to turn off on link down
        net: pcs: xpcs: fix incorrect steps on disable EEE
        netlink: annotate data races around nlk->bound
        net: pcs: xpcs: fix incorrect CL37 AN sequence
        net: sfp: Fix typo in state machine debug string
        net/sched: sch_taprio: properly cancel timer from taprio_destroy()
        net: bridge: fix under estimation in br_get_linkxstats_size()
        ...
      4a16df54
    • Linus Torvalds's avatar
      Merge tag 'hyperv-fixes-signed-20211007' of... · 52bf8031
      Linus Torvalds authored
      Merge tag 'hyperv-fixes-signed-20211007' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
      
      Pull hyperv fixes from Wei Liu:
      
       - Replace uuid.h with types.h in a header (Andy Shevchenko)
      
       - Avoid sleeping in atomic context in PCI driver (Long Li)
      
       - Avoid sending IPI to self when it shouldn't (Vitaly Kuznetsov)
      
      * tag 'hyperv-fixes-signed-20211007' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
        x86/hyperv: Avoid erroneously sending IPI to 'self'
        hyper-v: Replace uuid.h with types.h
        PCI: hv: Fix sleep while in non-sleep context when removing child devices from the bus
      52bf8031
    • Sven Peter's avatar
      MAINTAINERS: Add Sven Peter as ARM/APPLE MACHINE maintainer · 56dd0502
      Sven Peter authored
      Hector suggested I should add myself to help him maintain the
      platform.
      Acked-by: default avatarHector Martin <marcan@marcan.st>
      Signed-off-by: default avatarSven Peter <sven@svenpeter.dev>
      56dd0502
    • Alyssa Rosenzweig's avatar
      MAINTAINERS: Add Alyssa Rosenzweig as M1 reviewer · e47e3fa1
      Alyssa Rosenzweig authored
      Add myself as a reviewer for Asahi Linux (Apple M1) patches.
      
      I would like to be CC'ed on Asahi Linux patches for review and testing.
      I am also collecting Asahi Linux patches downstream, rebasing on
      linux-next periodically, and would like to be notified of what to
      cherry-pick from lists.
      
      Cc: Hector Martin <marcan@marcan.st>
      Cc: Sven Peter <sven@svenpeter.dev>
      Acked-by: default avatarHector Martin <marcan@marcan.st>
      Acked-by: default avatarSven Peter <sven@svenpeter.dev>
      Signed-off-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      e47e3fa1
    • Mike Manning's avatar
      net: prefer socket bound to interface when not in VRF · 8d6c414c
      Mike Manning authored
      The commit 6da5b0f0 ("net: ensure unbound datagram socket to be
      chosen when not in a VRF") modified compute_score() so that a device
      match is always made, not just in the case of an l3mdev skb, then
      increments the score also for unbound sockets. This ensures that
      sockets bound to an l3mdev are never selected when not in a VRF.
      But as unbound and bound sockets are now scored equally, this results
      in the last opened socket being selected if there are matches in the
      default VRF for an unbound socket and a socket bound to a dev that is
      not an l3mdev. However, handling prior to this commit was to always
      select the bound socket in this case. Reinstate this handling by
      incrementing the score only for bound sockets. The required isolation
      due to choosing between an unbound socket and a socket bound to an
      l3mdev remains in place due to the device match always being made.
      The same approach is taken for compute_score() for stream sockets.
      
      Fixes: 6da5b0f0 ("net: ensure unbound datagram socket to be chosen when not in a VRF")
      Fixes: e7819058 ("net: ensure unbound stream socket to be chosen when not in a VRF")
      Signed-off-by: default avatarMike Manning <mmanning@vyatta.att-mail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/cf0a8523-b362-1edf-ee78-eef63cbbb428@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8d6c414c
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 7671b026
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2021-10-07
      
      We've added 7 non-merge commits during the last 8 day(s) which contain
      a total of 8 files changed, 38 insertions(+), 21 deletions(-).
      
      The main changes are:
      
      1) Fix ARM BPF JIT to preserve caller-saved regs for DIV/MOD JIT-internal
         helper call, from Johan Almbladh.
      
      2) Fix integer overflow in BPF stack map element size calculation when
         used with preallocation, from Tatsuhiko Yasumatsu.
      
      3) Fix an AF_UNIX regression due to added BPF sockmap support related
         to shutdown handling, from Jiang Wang.
      
      4) Fix a segfault in libbpf when generating light skeletons from objects
         without BTF, from Kumar Kartikeya Dwivedi.
      
      5) Fix a libbpf memory leak in strset to free the actual struct strset
         itself, from Andrii Nakryiko.
      
      6) Dual-license bpf_insn.h similarly as we did for libbpf and bpftool,
         with ACKs from all contributors, from Luca Boccassi.
      ====================
      
      Link: https://lore.kernel.org/r/20211007135010.21143-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7671b026
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ · 578f3932
      David S. Miller authored
      ipsec
      
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2021-10-07
      
      1) Fix a sysbot reported shift-out-of-bounds in xfrm_get_default.
         From Pavel Skripkin.
      
      2) Fix XFRM_MSG_MAPPING ABI breakage. The new XFRM_MSG_MAPPING
         messages were accidentally not paced at the end.
         Fix by Eugene Syromiatnikov.
      
      3) Fix the uapi for the default policy, use explicit field and macros
         and make it accessible to userland.
         From Nicolas Dichtel.
      
      4) Fix a missing rcu lock in xfrm_notify_userpolicy().
         From Nicolas Dichtel.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      578f3932
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net- · 65f280bb
      David S. Miller authored
      queue
      
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2021-10-06
      
      This series contains updates to i40e and iavf drivers.
      
      Jiri Benc expands an error check to prevent infinite loop for i40e.
      
      Sylwester prevents freeing of uninitialized IRQ vector to resolve a
      kernel oops for i40e.
      
      Stefan Assmann fixes a double mutex unlock for iavf.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65f280bb
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux · 5af4055f
      Linus Torvalds authored
      Pull devicetree fixes from Rob Herring:
      
       - Add another allowed address for TI sn65dsi86
      
       - Drop more redundant minItems/maxItems
      
       - Fix more graph 'unevaluatedProperties' warnings in media bindings
      
      * tag 'devicetree-fixes-for-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
        dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg value
        dt-bindings: Drop more redundant 'maxItems/minItems'
        dt-bindings: media: Fix more graph 'unevaluatedProperties' related warnings
      5af4055f
  4. 06 Oct, 2021 4 commits
    • Benjamin Coddington's avatar
      NFSD: Keep existing listeners on portlist error · c2010694
      Benjamin Coddington authored
      If nfsd has existing listening sockets without any processes, then an error
      returned from svc_create_xprt() for an additional transport will remove
      those existing listeners.  We're seeing this in practice when userspace
      attempts to create rpcrdma transports without having the rpcrdma modules
      present before creating nfsd kernel processes.  Fix this by checking for
      existing sockets before calling nfsd_destroy().
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      c2010694
    • Stefan Assmann's avatar
      iavf: fix double unlock of crit_lock · 54ee3943
      Stefan Assmann authored
      The crit_lock mutex could be unlocked twice as reported here
      https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210823/025525.html
      
      Remove the superfluous unlock. Technically the problem was already
      present before 5ac49f3c as that commit only replaced the locking
      primitive, but no functional change.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 5ac49f3c ("iavf: use mutexes for locking of critical sections")
      Fixes: bac84861 ("iavf: Refactor the watchdog state machine")
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      54ee3943
    • Sylwester Dziedziuch's avatar
      i40e: Fix freeing of uninitialized misc IRQ vector · 2e5a2057
      Sylwester Dziedziuch authored
      When VSI set up failed in i40e_probe() as part of PF switch set up
      driver was trying to free misc IRQ vectors in
      i40e_clear_interrupt_scheme and produced a kernel Oops:
      
         Trying to free already-free IRQ 266
         WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
         Workqueue: events work_for_cpu_fn
         RIP: 0010:__free_irq+0x9a/0x300
         Call Trace:
         ? synchronize_irq+0x3a/0xa0
         free_irq+0x2e/0x60
         i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
         i40e_probe.part.108+0x134b/0x1a40 [i40e]
         ? kmem_cache_alloc+0x158/0x1c0
         ? acpi_ut_update_ref_count.part.1+0x8e/0x345
         ? acpi_ut_update_object_reference+0x15e/0x1e2
         ? strstr+0x21/0x70
         ? irq_get_irq_data+0xa/0x20
         ? mp_check_pin_attr+0x13/0xc0
         ? irq_get_irq_data+0xa/0x20
         ? mp_map_pin_to_irq+0xd3/0x2f0
         ? acpi_register_gsi_ioapic+0x93/0x170
         ? pci_conf1_read+0xa4/0x100
         ? pci_bus_read_config_word+0x49/0x70
         ? do_pci_enable_device+0xcc/0x100
         local_pci_probe+0x41/0x90
         work_for_cpu_fn+0x16/0x20
         process_one_work+0x1a7/0x360
         worker_thread+0x1cf/0x390
         ? create_worker+0x1a0/0x1a0
         kthread+0x112/0x130
         ? kthread_flush_work_fn+0x10/0x10
         ret_from_fork+0x1f/0x40
      
      The problem is that at that point misc IRQ vectors
      were not allocated yet and we get a call trace
      that driver is trying to free already free IRQ vectors.
      
      Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
      PF state before calling i40e_free_misc_vector. This state is set only if
      misc IRQ vectors were properly initialized.
      
      Fixes: c17401a1 ("i40e: use separate state bit for miscellaneous IRQ setup")
      Reported-by: default avatarPJ Waskiewicz <pwaskiewicz@jumptrading.com>
      Signed-off-by: default avatarSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
      Signed-off-by: default avatarMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      2e5a2057
    • Jiri Benc's avatar
      i40e: fix endless loop under rtnl · 857b6c6f
      Jiri Benc authored
      The loop in i40e_get_capabilities can never end. The problem is that
      although i40e_aq_discover_capabilities returns with an error if there's
      a firmware problem, the returned error is not checked. There is a check for
      pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most
      firmware problems.
      
      When i40e_aq_discover_capabilities encounters a firmware problem, it will
      encounter the same problem on its next invocation. As the result, the loop
      becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking
      at the code, it can happen with a range of other firmware errors.
      
      I don't know what the correct behavior should be: whether the firmware
      should be retried a few times, or whether pf->hw.aq.asq_last_status should
      be always set to the encountered firmware error (but then it would be
      pointless and can be just replaced by the i40e_aq_discover_capabilities
      return value). However, the current behavior with an endless loop under the
      rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we
      explained the bug to them 7 months ago.
      
      This may not be the best possible fix but it's better than hanging the whole
      system on a firmware bug.
      
      Fixes: 56a62fc8 ("i40e: init code and hardware support")
      Tested-by: default avatarStefan Assmann <sassmann@redhat.com>
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      857b6c6f