1. 01 Sep, 2019 8 commits
    • Igor Russkikh's avatar
      net: aquantia: linkstate irq should be oneshot · 5c47e3ba
      Igor Russkikh authored
      Declaring threaded irq handler should also indicate the irq is
      oneshot. It is oneshot indeed, because HW implements irq automasking
      on trigger.
      
      Not declaring this causes some kernel configurations to fail
      on interface up, because request_threaded_irq returned an err code.
      
      The issue was originally hidden on normal x86_64 configuration with
      latest kernel, because depending on interrupt controller, irq driver
      added ONESHOT flag on its own.
      
      Issue was observed on older kernels (4.14) where no such logic exists.
      
      Fixes: 4c83f170
      
       ("net: aquantia: link status irq handling")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Reported-by: default avatarMichael Symolkin <Michael.Symolkin@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c47e3ba
    • Dmitry Bogdanov's avatar
      net: aquantia: reapply vlan filters on up · c2ef057e
      Dmitry Bogdanov authored
      In case of device reconfiguration the driver may reset the device invisible
      for other modules, vlan module in particular. So vlans will not be
      removed&created and vlan filters will not be configured in the device.
      The patch reapplies the vlan filters at device start.
      
      Fixes: 7975d2af
      
       ("net: aquantia: add support of rx-vlan-filter offload")
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2ef057e
    • Dmitry Bogdanov's avatar
      net: aquantia: fix limit of vlan filters · 392349f6
      Dmitry Bogdanov authored
      Fix a limit condition of vlans on the interface before setting vlan
      promiscuous mode
      
      Fixes: 48dd73d0
      
       ("net: aquantia: fix vlans not working over bridged network")
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      392349f6
    • Dmitry Bogdanov's avatar
      net: aquantia: fix removal of vlan 0 · 6fdc060d
      Dmitry Bogdanov authored
      Due to absence of checking against the rx flow rule when vlan 0 is being
      removed, the other rule could be removed instead of the rule with vlan 0
      
      Fixes: 7975d2af
      
       ("net: aquantia: add support of rx-vlan-filter offload")
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fdc060d
    • David S. Miller's avatar
      Merge branch 'Fix-issues-in-tc-taprio-and-tc-cbs' · 154f4fb7
      David S. Miller authored
      
      
      Vladimir Oltean says:
      
      ====================
      Fix issues in tc-taprio and tc-cbs
      
      This series fixes one panic and one WARN_ON found in the tc-taprio
      qdisc, while trying to apply it:
      
      - On an interface which is not multi-queue
      - On an interface which has no carrier
      
      The tc-cbs was also visually found to suffer of the same issue as
      tc-taprio, and the fix was only compile-tested in that case.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      154f4fb7
    • Vladimir Oltean's avatar
      net/sched: cbs: Set default link speed to 10 Mbps in cbs_set_port_rate · 1c6c09a0
      Vladimir Oltean authored
      The discussion to be made is absolutely the same as in the case of
      previous patch ("taprio: Set default link speed to 10 Mbps in
      taprio_set_picos_per_byte"). Nothing is lost when setting a default.
      
      Cc: Leandro Dorileo <leandro.maciel.dorileo@intel.com>
      Fixes: e0a7683d
      
       ("net/sched: cbs: fix port_rate miscalculation")
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c6c09a0
    • Vladimir Oltean's avatar
      taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte · f04b514c
      Vladimir Oltean authored
      The taprio budget needs to be adapted at runtime according to interface
      link speed. But that handling is problematic.
      
      For one thing, installing a qdisc on an interface that doesn't have
      carrier is not illegal. But taprio prints the following stack trace:
      
      [   31.851373] ------------[ cut here ]------------
      [   31.856024] WARNING: CPU: 1 PID: 207 at net/sched/sch_taprio.c:481 taprio_dequeue+0x1a8/0x2d4
      [   31.864566] taprio: dequeue() called with unknown picos per byte.
      [   31.864570] Modules linked in:
      [   31.873701] CPU: 1 PID: 207 Comm: tc Not tainted 5.3.0-rc5-01199-g8838fe023cd6 #1689
      [   31.881398] Hardware name: Freescale LS1021A
      [   31.885661] [<c03133a4>] (unwind_backtrace) from [<c030d8cc>] (show_stack+0x10/0x14)
      [   31.893368] [<c030d8cc>] (show_stack) from [<c10ac958>] (dump_stack+0xb4/0xc8)
      [   31.900555] [<c10ac958>] (dump_stack) from [<c0349d04>] (__warn+0xe0/0xf8)
      [   31.907395] [<c0349d04>] (__warn) from [<c0349d64>] (warn_slowpath_fmt+0x48/0x6c)
      [   31.914841] [<c0349d64>] (warn_slowpath_fmt) from [<c0f38db4>] (taprio_dequeue+0x1a8/0x2d4)
      [   31.923150] [<c0f38db4>] (taprio_dequeue) from [<c0f227b0>] (__qdisc_run+0x90/0x61c)
      [   31.930856] [<c0f227b0>] (__qdisc_run) from [<c0ec82ac>] (net_tx_action+0x12c/0x2bc)
      [   31.938560] [<c0ec82ac>] (net_tx_action) from [<c0302298>] (__do_softirq+0x130/0x3c8)
      [   31.946350] [<c0302298>] (__do_softirq) from [<c03502a0>] (irq_exit+0xbc/0xd8)
      [   31.953536] [<c03502a0>] (irq_exit) from [<c03a4808>] (__handle_domain_irq+0x60/0xb4)
      [   31.961328] [<c03a4808>] (__handle_domain_irq) from [<c0754478>] (gic_handle_irq+0x58/0x9c)
      [   31.969638] [<c0754478>] (gic_handle_irq) from [<c0301a8c>] (__irq_svc+0x6c/0x90)
      [   31.977076] Exception stack(0xe8167b20 to 0xe8167b68)
      [   31.982100] 7b20: e9d4bd80 00000cc0 000000cf 00000000 e9d4bd80 c1f38958 00000cc0 c1f38960
      [   31.990234] 7b40: 00000001 000000cf 00000004 e9dc0800 00000000 e8167b70 c0f478ec c0f46d94
      [   31.998363] 7b60: 60070013 ffffffff
      [   32.001833] [<c0301a8c>] (__irq_svc) from [<c0f46d94>] (netlink_trim+0x18/0xd8)
      [   32.009104] [<c0f46d94>] (netlink_trim) from [<c0f478ec>] (netlink_broadcast_filtered+0x34/0x414)
      [   32.017930] [<c0f478ec>] (netlink_broadcast_filtered) from [<c0f47cec>] (netlink_broadcast+0x20/0x28)
      [   32.027102] [<c0f47cec>] (netlink_broadcast) from [<c0eea378>] (rtnetlink_send+0x34/0x88)
      [   32.035238] [<c0eea378>] (rtnetlink_send) from [<c0f25890>] (notify_and_destroy+0x2c/0x44)
      [   32.043461] [<c0f25890>] (notify_and_destroy) from [<c0f25e08>] (qdisc_graft+0x398/0x470)
      [   32.051595] [<c0f25e08>] (qdisc_graft) from [<c0f27a00>] (tc_modify_qdisc+0x3a4/0x724)
      [   32.059470] [<c0f27a00>] (tc_modify_qdisc) from [<c0ee4c84>] (rtnetlink_rcv_msg+0x260/0x2ec)
      [   32.067864] [<c0ee4c84>] (rtnetlink_rcv_msg) from [<c0f4a988>] (netlink_rcv_skb+0xb8/0x110)
      [   32.076172] [<c0f4a988>] (netlink_rcv_skb) from [<c0f4a170>] (netlink_unicast+0x1b4/0x22c)
      [   32.084392] [<c0f4a170>] (netlink_unicast) from [<c0f4a5e4>] (netlink_sendmsg+0x33c/0x380)
      [   32.092614] [<c0f4a5e4>] (netlink_sendmsg) from [<c0ea9f40>] (sock_sendmsg+0x14/0x24)
      [   32.100403] [<c0ea9f40>] (sock_sendmsg) from [<c0eaa780>] (___sys_sendmsg+0x214/0x228)
      [   32.108279] [<c0eaa780>] (___sys_sendmsg) from [<c0eabad0>] (__sys_sendmsg+0x50/0x8c)
      [   32.116068] [<c0eabad0>] (__sys_sendmsg) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
      [   32.123938] Exception stack(0xe8167fa8 to 0xe8167ff0)
      [   32.128960] 7fa0:                   b6fa68c8 000000f8 00000003 bea142d0 00000000 00000000
      [   32.137093] 7fc0: b6fa68c8 000000f8 0052154c 00000128 5d6468a2 00000000 00000028 00558c9c
      [   32.145224] 7fe0: 00000070 bea14278 00530d64 b6e17e64
      [   32.150659] ---[ end trace 2139c9827c3e5177 ]---
      
      This happens because the qdisc ->dequeue callback gets called. Which
      again is not illegal, the qdisc will dequeue even when the interface is
      up but doesn't have carrier (and hence SPEED_UNKNOWN), and the frames
      will be dropped further down the stack in dev_direct_xmit().
      
      And, at the end of the day, for what? For calculating the initial budget
      of an interface which is non-operational at the moment and where frames
      will get dropped anyway.
      
      So if we can't figure out the link speed, default to SPEED_10 and move
      along. We can also remove the runtime check now.
      
      Cc: Leandro Dorileo <leandro.maciel.dorileo@intel.com>
      Fixes: 7b9eba7b
      
       ("net/sched: taprio: fix picos_per_byte miscalculation")
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f04b514c
    • Vladimir Oltean's avatar
      taprio: Fix kernel panic in taprio_destroy · efb55222
      Vladimir Oltean authored
      taprio_init may fail earlier than this line:
      
      	list_add(&q->taprio_list, &taprio_list);
      
      i.e. due to the net device not being multi queue.
      
      Attempting to remove q from the global taprio_list when it is not part
      of it will result in a kernel panic.
      
      Fix it by matching list_add and list_del better to one another in the
      order of operations. This way we can keep the deletion unconditional
      and with lower complexity - O(1).
      
      Cc: Leandro Dorileo <leandro.maciel.dorileo@intel.com>
      Fixes: 7b9eba7b
      
       ("net/sched: taprio: fix picos_per_byte miscalculation")
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      efb55222
  2. 31 Aug, 2019 4 commits
  3. 30 Aug, 2019 5 commits
    • David Howells's avatar
      rxrpc: Fix lack of conn cleanup when local endpoint is cleaned up [ver #2] · d12040b6
      David Howells authored
      When a local endpoint is ceases to be in use, such as when the kafs module
      is unloaded, the kernel will emit an assertion failure if there are any
      outstanding client connections:
      
      	rxrpc: Assertion failed
      	------------[ cut here ]------------
      	kernel BUG at net/rxrpc/local_object.c:433!
      
      and even beyond that, will evince other oopses if there are service
      connections still present.
      
      Fix this by:
      
       (1) Removing the triggering of connection reaping when an rxrpc socket is
           released.  These don't actually clean up the connections anyway - and
           further, the local endpoint may still be in use through another
           socket.
      
       (2) Mark the local endpoint as dead when we start the process of tearing
           it down.
      
       (3) When destroying a local endpoint, strip all of its client connections
           from the idle list and discard the ref on each that the list was
           holding.
      
       (4) When destroying a local endpoint, call the service connection reaper
           directly (rather than through a workqueue) to immediately kill off all
           outstanding service connections.
      
       (5) Make the service connection reaper reap connections for which the
           local endpoint is marked dead.
      
      Only after destroying the connections can we close the socket lest we get
      an oops in a workqueue that's looking at a connection or a peer.
      
      Fixes: 3d18cbb7
      
       ("rxrpc: Fix conn expiry timers")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d12040b6
    • David S. Miller's avatar
      Merge tag 'rxrpc-fixes-20190827' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · a285c1fa
      David S. Miller authored
      
      
      David Howells says:
      
      ====================
      rxrpc: Fix use of skb_cow_data()
      
      Here's a series of patches that replaces the use of skb_cow_data() in rxrpc
      with skb_unshare() early on in the input process.  The problem that is
      being seen is that skb_cow_data() indirectly requires that the maximum
      usage count on an sk_buff be 1, and it may generate an assertion failure in
      pskb_expand_head() if not.
      
      This can occur because rxrpc_input_data() may be still holding a ref when
      it has just attached the sk_buff to the rx ring and given that attachment
      its own ref.  If recvmsg happens fast enough, skb_cow_data() can see the
      ref still held by the softirq handler.
      
      Further, a packet may contain multiple subpackets, each of which gets its
      own attachment to the ring and its own ref - also making skb_cow_data() go
      bang.
      
      Fix this by:
      
       (1) The DATA packet is currently parsed for subpackets twice by the input
           routines.  Parse it just once instead and make notes in the sk_buff
           private data.
      
       (2) Use the notes from (1) when attaching the packet to the ring multiple
           times.  Once the packet is attached to the ring, recvmsg can see it
           and start modifying it, so the softirq handler is not permitted to
           look inside it from that point.
      
       (3) Pass the ref from the input code to the ring rather than getting an
           extra ref.  rxrpc_input_data() uses a ref on the second refcount to
           prevent the packet from evaporating under it.
      
       (4) Call skb_unshare() on secured DATA packets in rxrpc_input_packet()
           before we take call->input_lock.  Other sorts of packets don't get
           modified and so can be left.
      
           A trace is emitted if skb_unshare() eats the skb.  Note that
           skb_share() for our accounting in this regard as we can't see the
           parameters in the packet to log in a trace line if it releases it.
      
       (5) Remove the calls to skb_cow_data().  These are then no longer
           necessary.
      
      There are also patches to improve the rxrpc_skb tracepoint to make sure
      that Tx-derived buffers are identified separately from Rx-derived buffers
      in the trace.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a285c1fa
    • Chen-Yu Tsai's avatar
      net: stmmac: dwmac-rk: Don't fail if phy regulator is absent · 3b25528e
      Chen-Yu Tsai authored
      The devicetree binding lists the phy phy as optional. As such, the
      driver should not bail out if it can't find a regulator. Instead it
      should just skip the remaining regulator related code and continue
      on normally.
      
      Skip the remainder of phy_power_on() if a regulator supply isn't
      available. This also gets rid of the bogus return code.
      
      Fixes: 2e12f536
      
       ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b25528e
    • YueHaibing's avatar
      amd-xgbe: Fix error path in xgbe_mod_init() · b6b4dc4c
      YueHaibing authored
      
      
      In xgbe_mod_init(), we should do cleanup if some error occurs
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: efbaa828 ("amd-xgbe: Add support to handle device renaming")
      Fixes: 47f164de
      
       ("amd-xgbe: Add PCI device support")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6b4dc4c
    • wenxu's avatar
      netfilter: nft_meta_bridge: Fix get NFT_META_BRI_IIFVPROTO in network byteorder · daf1de90
      wenxu authored
      Get the vlan_proto of ingress bridge in network byteorder as userspace
      expects. Otherwise this is inconsistent with NFT_META_PROTOCOL.
      
      Fixes: 2a3a93ef
      
       ("netfilter: nft_meta_bridge: Add NFT_META_BRI_IIFVPROTO support")
      Signed-off-by: default avatarwenxu <wenxu@ucloud.cn>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      daf1de90
  4. 29 Aug, 2019 5 commits
  5. 28 Aug, 2019 18 commits
    • Takashi Iwai's avatar
      sky2: Disable MSI on yet another ASUS boards (P6Xxxx) · 189308d5
      Takashi Iwai authored
      
      
      A similar workaround for the suspend/resume problem is needed for yet
      another ASUS machines, P6X models.  Like the previous fix, the BIOS
      doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_*
      entries are used instead.
      
      Reported-and-tested-by: default avatarSteveM <swm@swm1.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      189308d5
    • David S. Miller's avatar
      Merge branch 'nfp-flower-fix-bugs-in-merge-tunnel-encap-code' · 807e3299
      David S. Miller authored
      
      
      Jakub Kicinski says:
      
      ====================
      nfp: flower: fix bugs in merge tunnel encap code
      
      John says:
      
      There are few bugs in the merge encap code that have come to light with
      recent driver changes. Effectively, flow bind callbacks were being
      registered twice when using internal ports (new 'busy' code triggers
      this). There was also an issue with neighbour notifier messages being
      ignored for internal ports.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      807e3299
    • John Hurley's avatar
      nfp: flower: handle neighbour events on internal ports · e8024cb4
      John Hurley authored
      Recent code changes to NFP allowed the offload of neighbour entries to FW
      when the next hop device was an internal port. This allows for offload of
      tunnel encap when the end-point IP address is applied to such a port.
      
      Unfortunately, the neighbour event handler still rejects events that are
      not associated with a repr dev and so the firmware neighbour table may get
      out of sync for internal ports.
      
      Fix this by allowing internal port neighbour events to be correctly
      processed.
      
      Fixes: 45756dfe
      
       ("nfp: flower: allow tunnels to output to internal port")
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8024cb4
    • John Hurley's avatar
      nfp: flower: prevent ingress block binds on internal ports · 739d7c57
      John Hurley authored
      Internal port TC offload is implemented through user-space applications
      (such as OvS) by adding filters at egress via TC clsact qdiscs. Indirect
      block offload support in the NFP driver accepts both ingress qdisc binds
      and egress binds if the device is an internal port. However, clsact sends
      bind notification for both ingress and egress block binds which can lead
      to the driver registering multiple callbacks and receiving multiple
      notifications of new filters.
      
      Fix this by rejecting ingress block bind callbacks when the port is
      internal and only adding filter callbacks for egress binds.
      
      Fixes: 4d12ba42
      
       ("nfp: flower: allow offloading of matches on 'internal' ports")
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      739d7c57
    • David S. Miller's avatar
      Merge branch 'r8152-fix-side-effect' · 80a6a5d6
      David S. Miller authored
      Hayes Wang says:
      
      ====================
      r8152: fix side effect
      
      v3:
      Update the commit message for patch #1.
      
      v2:
      Replace patch #2 with "r8152: remove calling netif_napi_del".
      
      v1:
      The commit 0ee1f473 ("r8152: napi hangup fix after disconnect")
      add a check to avoid using napi_disable after netif_napi_del. However,
      the commit ffa9fec3 ("r8152: set RTL8152_UNPLUG only for real
      disconnection") let the check useless.
      
      Therefore, I revert commit 0ee1f473
      
       ("r8152: napi hangup fix
      after disconnect") first, and add another patch to fix it.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80a6a5d6
    • Hayes Wang's avatar
      r8152: remove calling netif_napi_del · 973dc6cf
      Hayes Wang authored
      
      
      Remove unnecessary use of netif_napi_del. This also avoids to call
      napi_disable() after netif_napi_del().
      
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      973dc6cf
    • Hayes Wang's avatar
      Revert "r8152: napi hangup fix after disconnect" · 49d4b141
      Hayes Wang authored
      This reverts commit 0ee1f473.
      
      The commit 0ee1f473 ("r8152: napi hangup fix after
      disconnect") adds a check about RTL8152_UNPLUG to determine
      if calling napi_disable() is invalid in rtl8152_close(),
      when rtl8152_disconnect() is called. This avoids to use
      napi_disable() after calling netif_napi_del().
      
      Howver, commit ffa9fec3 ("r8152: set RTL8152_UNPLUG
      only for real disconnection") causes that RTL8152_UNPLUG
      is not always set when calling rtl8152_disconnect().
      Therefore, I have to revert commit 0ee1f473
      
       ("r8152:
      napi hangup fix after disconnect"), first. And submit
      another patch to fix it.
      
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49d4b141
    • Davide Caratti's avatar
      net/sched: pfifo_fast: fix wrong dereference in pfifo_fast_enqueue · 092e22e5
      Davide Caratti authored
      Now that 'TCQ_F_CPUSTATS' bit can be cleared, depending on the value of
      'TCQ_F_NOLOCK' bit in the parent qdisc, we can't assume anymore that
      per-cpu counters are there in the error path of skb_array_produce().
      Otherwise, the following splat can be seen:
      
       Unable to handle kernel paging request at virtual address 0000600dea430008
       Mem abort info:
         ESR = 0x96000005
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000005
         CM = 0, WnR = 0
       user pgtable: 64k pages, 48-bit VAs, pgdp = 000000007b97530e
       [0000600dea430008] pgd=0000000000000000, pud=0000000000000000
       Internal error: Oops: 96000005 [#1] SMP
      [...]
       pstate: 10000005 (nzcV daif -PAN -UAO)
       pc : pfifo_fast_enqueue+0x524/0x6e8
       lr : pfifo_fast_enqueue+0x46c/0x6e8
       sp : ffff800d39376fe0
       x29: ffff800d39376fe0 x28: 1ffff001a07d1e40
       x27: ffff800d03e8f188 x26: ffff800d03e8f200
       x25: 0000000000000062 x24: ffff800d393772f0
       x23: 0000000000000000 x22: 0000000000000403
       x21: ffff800cca569a00 x20: ffff800d03e8ee00
       x19: ffff800cca569a10 x18: 00000000000000bf
       x17: 0000000000000000 x16: 0000000000000000
       x15: 0000000000000000 x14: ffff1001a726edd0
       x13: 1fffe4000276a9a4 x12: 0000000000000000
       x11: dfff200000000000 x10: ffff800d03e8f1a0
       x9 : 0000000000000003 x8 : 0000000000000000
       x7 : 00000000f1f1f1f1 x6 : ffff1001a726edea
       x5 : ffff800cca56a53c x4 : 1ffff001bf9a8003
       x3 : 1ffff001bf9a8003 x2 : 1ffff001a07d1dcb
       x1 : 0000600dea430000 x0 : 0000600dea430008
       Process ping (pid: 6067, stack limit = 0x00000000dc0aa557)
       Call trace:
        pfifo_fast_enqueue+0x524/0x6e8
        htb_enqueue+0x660/0x10e0 [sch_htb]
        __dev_queue_xmit+0x123c/0x2de0
        dev_queue_xmit+0x24/0x30
        ip_finish_output2+0xc48/0x1720
        ip_finish_output+0x548/0x9d8
        ip_output+0x334/0x788
        ip_local_out+0x90/0x138
        ip_send_skb+0x44/0x1d0
        ip_push_pending_frames+0x5c/0x78
        raw_sendmsg+0xed8/0x28d0
        inet_sendmsg+0xc4/0x5c0
        sock_sendmsg+0xac/0x108
        __sys_sendto+0x1ac/0x2a0
        __arm64_sys_sendto+0xc4/0x138
        el0_svc_handler+0x13c/0x298
        el0_svc+0x8/0xc
       Code: f9402e80 d538d081 91002000 8b010000 (885f7c03)
      
      Fix this by testing the value of 'TCQ_F_CPUSTATS' bit in 'qdisc->flags',
      before dereferencing 'qdisc->cpu_qstats'.
      
      Fixes: 8a53e616
      
       ("net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too")
      CC: Paolo Abeni <pabeni@redhat.com>
      CC: Stefano Brivio <sbrivio@redhat.com>
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      092e22e5
    • Willem de Bruijn's avatar
      tcp: inherit timestamp on mtu probe · 888a5c53
      Willem de Bruijn authored
      TCP associates tx timestamp requests with a byte in the bytestream.
      If merging skbs in tcp_mtu_probe, migrate the tstamp request.
      
      Similar to MSG_EOR, do not allow moving a timestamp from any segment
      in the probe but the last. This to avoid merging multiple timestamps.
      
      Tested with the packetdrill script at
      https://github.com/wdebruij/packetdrill/commits/mtu_probe-1
      
      Link: http://patchwork.ozlabs.org/patch/1143278/#2232897
      Fixes: 4ed2d765
      
       ("net-timestamp: TCP timestamping")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      888a5c53
    • Vlad Buslov's avatar
      net: sched: act_sample: fix psample group handling on overwrite · dbf47a2a
      Vlad Buslov authored
      Action sample doesn't properly handle psample_group pointer in overwrite
      case. Following issues need to be fixed:
      
      - In tcf_sample_init() function RCU_INIT_POINTER() is used to set
        s->psample_group, even though we neither setting the pointer to NULL, nor
        preventing concurrent readers from accessing the pointer in some way.
        Use rcu_swap_protected() instead to safely reset the pointer.
      
      - Old value of s->psample_group is not released or deallocated in any way,
        which results resource leak. Use psample_group_put() on non-NULL value
        obtained with rcu_swap_protected().
      
      - The function psample_group_put() that released reference to struct
        psample_group pointed by rcu-pointer s->psample_group doesn't respect rcu
        grace period when deallocating it. Extend struct psample_group with rcu
        head and use kfree_rcu when freeing it.
      
      Fixes: 5c5670fa
      
       ("net/sched: Introduce sample tc action")
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbf47a2a
    • Thomas Falcon's avatar
      ibmvnic: Do not process reset during or after device removal · 36f1031c
      Thomas Falcon authored
      
      
      Currently, the ibmvnic driver will not schedule device resets
      if the device is being removed, but does not check the device
      state before the reset is actually processed. This leads to a race
      where a reset is scheduled with a valid device state but is
      processed after the driver has been removed, resulting in an oops.
      
      Fix this by checking the device state before processing a queued
      reset event.
      
      Reported-by: default avatarAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Tested-by: default avatarAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36f1031c
    • Justin Pettit's avatar
      openvswitch: Clear the L4 portion of the key for "later" fragments. · 0754b4e8
      Justin Pettit authored
      
      
      Only the first fragment in a datagram contains the L4 headers.  When the
      Open vSwitch module parses a packet, it always sets the IP protocol
      field in the key, but can only set the L4 fields on the first fragment.
      The original behavior would not clear the L4 portion of the key, so
      garbage values would be sent in the key for "later" fragments.  This
      patch clears the L4 fields in that circumstance to prevent sending those
      garbage values as part of the upcall.
      
      Signed-off-by: default avatarJustin Pettit <jpettit@ovn.org>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0754b4e8
    • Greg Rose's avatar
      openvswitch: Properly set L4 keys on "later" IP fragments · ad06a566
      Greg Rose authored
      
      
      When IP fragments are reassembled before being sent to conntrack, the
      key from the last fragment is used.  Unless there are reordering
      issues, the last fragment received will not contain the L4 ports, so the
      key for the reassembled datagram won't contain them.  This patch updates
      the key once we have a reassembled datagram.
      
      The handle_fragments() function works on L3 headers so we pull the L3/L4
      flow key update code from key_extract into a new function
      'key_extract_l3l4'.  Then we add a another new function
      ovs_flow_key_update_l3l4() and export it so that it is accessible by
      handle_fragments() for conntrack packet reassembly.
      
      Co-authored-by: default avatarJustin Pettit <jpettit@ovn.org>
      Signed-off-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad06a566
    • Eric Dumazet's avatar
      mld: fix memory leak in mld_del_delrec() · a84d0164
      Eric Dumazet authored
      Similar to the fix done for IPv4 in commit e5b1c6c6
      ("igmp: fix memory leak in igmpv3_del_delrec()"), we need to
      make sure mca_tomb and mca_sources are not blindly overwritten.
      
      Using swap() then a call to ip6_mc_clear_src() will take care
      of the missing free.
      
      BUG: memory leak
      unreferenced object 0xffff888117d9db00 (size 64):
        comm "syz-executor247", pid 6918, jiffies 4294943989 (age 25.350s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 fe 88 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000005b463030>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
          [<000000005b463030>] slab_post_alloc_hook mm/slab.h:522 [inline]
          [<000000005b463030>] slab_alloc mm/slab.c:3319 [inline]
          [<000000005b463030>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
          [<00000000939cbf94>] kmalloc include/linux/slab.h:552 [inline]
          [<00000000939cbf94>] kzalloc include/linux/slab.h:748 [inline]
          [<00000000939cbf94>] ip6_mc_add1_src net/ipv6/mcast.c:2236 [inline]
          [<00000000939cbf94>] ip6_mc_add_src+0x31f/0x420 net/ipv6/mcast.c:2356
          [<00000000d8972221>] ip6_mc_source+0x4a8/0x600 net/ipv6/mcast.c:449
          [<000000002b203d0d>] do_ipv6_setsockopt.isra.0+0x1b92/0x1dd0 net/ipv6/ipv6_sockglue.c:748
          [<000000001f1e2d54>] ipv6_setsockopt+0x89/0xd0 net/ipv6/ipv6_sockglue.c:944
          [<00000000c8f7bdf9>] udpv6_setsockopt+0x4e/0x90 net/ipv6/udp.c:1558
          [<000000005a9a0c5e>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3139
          [<00000000910b37b2>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
          [<00000000e9108023>] __do_sys_setsockopt net/socket.c:2100 [inline]
          [<00000000e9108023>] __se_sys_setsockopt net/socket.c:2097 [inline]
          [<00000000e9108023>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
          [<00000000f4818160>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
          [<000000008d367e8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1666d49e ("mld: do not remove mld souce list info when set link down")
      Fixes: 9c8bb163
      
       ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a84d0164
    • Davide Caratti's avatar
      net/sched: pfifo_fast: fix wrong dereference when qdisc is reset · 04d37cf4
      Davide Caratti authored
      Now that 'TCQ_F_CPUSTATS' bit can be cleared, depending on the value of
      'TCQ_F_NOLOCK' bit in the parent qdisc, we need to be sure that per-cpu
      counters are present when 'reset()' is called for pfifo_fast qdiscs.
      Otherwise, the following script:
      
       # tc q a dev lo handle 1: root htb default 100
       # tc c a dev lo parent 1: classid 1:100 htb \
       > rate 95Mbit ceil 100Mbit burst 64k
       [...]
       # tc f a dev lo parent 1: protocol arp basic classid 1:100
       [...]
       # tc q a dev lo parent 1:100 handle 100: pfifo_fast
       [...]
       # tc q d dev lo root
      
      can generate the following splat:
      
       Unable to handle kernel paging request at virtual address dfff2c01bd148000
       Mem abort info:
         ESR = 0x96000004
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000004
         CM = 0, WnR = 0
       [dfff2c01bd148000] address between user and kernel address ranges
       Internal error: Oops: 96000004 [#1] SMP
       [...]
       pstate: 80000005 (Nzcv daif -PAN -UAO)
       pc : pfifo_fast_reset+0x280/0x4d8
       lr : pfifo_fast_reset+0x21c/0x4d8
       sp : ffff800d09676fa0
       x29: ffff800d09676fa0 x28: ffff200012ee22e4
       x27: dfff200000000000 x26: 0000000000000000
       x25: ffff800ca0799958 x24: ffff1001940f332b
       x23: 0000000000000007 x22: ffff200012ee1ab8
       x21: 0000600de8a40000 x20: 0000000000000000
       x19: ffff800ca0799900 x18: 0000000000000000
       x17: 0000000000000002 x16: 0000000000000000
       x15: 0000000000000000 x14: 0000000000000000
       x13: 0000000000000000 x12: ffff1001b922e6e2
       x11: 1ffff001b922e6e1 x10: 0000000000000000
       x9 : 1ffff001b922e6e1 x8 : dfff200000000000
       x7 : 0000000000000000 x6 : 0000000000000000
       x5 : 1fffe400025dc45c x4 : 1fffe400025dc357
       x3 : 00000c01bd148000 x2 : 0000600de8a40000
       x1 : 0000000000000007 x0 : 0000600de8a40004
       Call trace:
        pfifo_fast_reset+0x280/0x4d8
        qdisc_reset+0x6c/0x370
        htb_reset+0x150/0x3b8 [sch_htb]
        qdisc_reset+0x6c/0x370
        dev_deactivate_queue.constprop.5+0xe0/0x1a8
        dev_deactivate_many+0xd8/0x908
        dev_deactivate+0xe4/0x190
        qdisc_graft+0x88c/0xbd0
        tc_get_qdisc+0x418/0x8a8
        rtnetlink_rcv_msg+0x3a8/0xa78
        netlink_rcv_skb+0x18c/0x328
        rtnetlink_rcv+0x28/0x38
        netlink_unicast+0x3c4/0x538
        netlink_sendmsg+0x538/0x9a0
        sock_sendmsg+0xac/0xf8
        ___sys_sendmsg+0x53c/0x658
        __sys_sendmsg+0xc8/0x140
        __arm64_sys_sendmsg+0x74/0xa8
        el0_svc_handler+0x164/0x468
        el0_svc+0x10/0x14
       Code: 910012a0 92400801 d343fc03 11000c21 (38fb6863)
      
      Fix this by testing the value of 'TCQ_F_CPUSTATS' bit in 'qdisc->flags',
      before dereferencing 'qdisc->cpu_qstats'.
      
      Changes since v1:
       - coding style improvements, thanks to Stefano Brivio
      
      Fixes: 8a53e616
      
       ("net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too")
      CC: Paolo Abeni <pabeni@redhat.com>
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04d37cf4
    • David S. Miller's avatar
      Merge branch 'macb-Update-ethernet-compatible-string-for-SiFive-FU540' · 2965daa3
      David S. Miller authored
      
      
      Yash Shah says:
      
      ====================
      macb: Update ethernet compatible string for SiFive FU540
      
      This patch series renames the compatible property to a more appropriate
      string. The patchset is based on Linux-5.3-rc6 and tested on SiFive
      Unleashed board
      
      Change history:
      Since v1:
      - Dropped PATCH3 because it's already merged
      - Change the reference url in the patch descriptions to point to a
        'lore.kernel.org' link instead of 'lkml.org'
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2965daa3
    • Yash Shah's avatar
      macb: Update compatibility string for SiFive FU540-C000 · 6342ea88
      Yash Shah authored
      Update the compatibility string for SiFive FU540-C000 as per the new
      string updated in the binding doc.
      Reference:
      https://lore.kernel.org/netdev/CAJ2_jOFEVZQat0Yprg4hem4jRrqkB72FKSeQj4p8P5KA-+rgww@mail.gmail.com/
      
      
      
      Signed-off-by: default avatarYash Shah <yash.shah@sifive.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Reviewed-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Tested-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6342ea88
    • Yash Shah's avatar
      macb: bindings doc: update sifive fu540-c000 binding · abecec41
      Yash Shah authored
      As per the discussion with Nicolas Ferre[0], rename the compatible property
      to a more appropriate and specific string.
      
      [0] https://lore.kernel.org/netdev/CAJ2_jOFEVZQat0Yprg4hem4jRrqkB72FKSeQj4p8P5KA-+rgww@mail.gmail.com/
      
      
      
      Signed-off-by: default avatarYash Shah <yash.shah@sifive.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Reviewed-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abecec41