Skip to content
  1. Aug 31, 2022
  2. Aug 26, 2022
    • Deren Wu's avatar
      wifi: mt76: mt7921e: fix crash in chip reset fail · fa3fbe64
      Deren Wu authored
      In case of drv own fail in reset, we may need to run mac_reset several
      times. The sequence would trigger system crash as the log below.
      
      Because we do not re-enable/schedule "tx_napi" before disable it again,
      the process would keep waiting for state change in napi_diable(). To
      avoid the problem and keep status synchronize for each run, goto final
      resource handling if drv own failed.
      
      [ 5857.353423] mt7921e 0000:3b:00.0: driver own failed
      [ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own
      [ 5859.633430] mt7921e 0000:3b:00.0: driver own failed
      [ 5859.633444] ------------[ cut here ]------------
      [ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d
      [ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
      [ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150
      [ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202
      ......
      [ 5859.633766] Call Trace:
      [ 5859.633768]  <TASK>
      [ 5859.633771]  mt7921e_mac_reset+0x176/0x6f0 [mt7921e]
      [ 5859.633778]  mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]
      [ 5859.633785]  ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]
      [ 5859.633794]  ? __kasan_check_read+0x11/0x20
      [ 5859.633802]  process_one_work+0x7ee/0x1320
      [ 5859.633810]  worker_thread+0x53c/0x1240
      [ 5859.633818]  kthread+0x2b8/0x370
      [ 5859.633824]  ? process_one_work+0x1320/0x1320
      [ 5859.633828]  ? kthread_complete_and_exit+0x30/0x30
      [ 5859.633834]  ret_from_fork+0x1f/0x30
      [ 5859.633842]  </TASK>
      
      Cc: stable@vger.kernel.org
      Fixes: 0efaf31d
      
       ("mt76: mt7921: fix MT7921E reset failure")
      Signed-off-by: default avatarDeren Wu <deren.wu@mediatek.com>
      Link: https://lore.kernel.org/r/727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com
      
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fa3fbe64
    • David S. Miller's avatar
      Merge tag 'wireless-2022-08-26' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless · 4ba9d38b
      David S. Miller authored
      
      
      Johannes Berg says:
      
      ====================
      pull-request: wireless-2022-08-26
      
      Here are a couple of fixes for the current cycle,
      see the tag description below.
      
      Just a couple of fixes:
       * two potential leaks
       * use-after-free in certain scan races
       * warning in IBSS code
       * error return from a debugfs file was wrong
       * possible NULL-ptr-deref when station lookup fails
      
      Please pull and let me know if there's any problem.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ba9d38b
    • Linus Torvalds's avatar
      Merge tag 'net-6.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 4c612826
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from ipsec and netfilter (with one broken Fixes tag).
      
        Current release - new code bugs:
      
         - dsa: don't dereference NULL extack in dsa_slave_changeupper()
      
         - dpaa: fix <1G ethernet on LS1046ARDB
      
         - neigh: don't call kfree_skb() under spin_lock_irqsave()
      
        Previous releases - regressions:
      
         - r8152: fix the RX FIFO settings when suspending
      
         - dsa: microchip: keep compatibility with device tree blobs with no
           phy-mode
      
         - Revert "net: macsec: update SCI upon MAC address change."
      
         - Revert "xfrm: update SA curlft.use_time", comply with RFC 2367
      
        Previous releases - always broken:
      
         - netfilter: conntrack: work around exceeded TCP receive window
      
         - ipsec: fix a null pointer dereference of dst->dev on a metadata dst
           in xfrm_lookup_with_ifid
      
         - moxa: get rid of asymmetry in DMA mapping/unmapping
      
         - dsa: microchip: make learning configurable and keep it off while
           standalone
      
         - ice: xsk: prohibit usage of non-balanced queue id
      
         - rxrpc: fix locking in rxrpc's sendmsg
      
        Misc:
      
         - another chunk of sysctl data race silencing"
      
      * tag 'net-6.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (87 commits)
        net: lantiq_xrx200: restore buffer if memory allocation failed
        net: lantiq_xrx200: fix lock under memory pressure
        net: lantiq_xrx200: confirm skb is allocated before using
        net: stmmac: work around sporadic tx issue on link-up
        ionic: VF initial random MAC address if no assigned mac
        ionic: fix up issues with handling EAGAIN on FW cmds
        ionic: clear broken state on generation change
        rxrpc: Fix locking in rxrpc's sendmsg
        net: ethernet: mtk_eth_soc: fix hw hash reporting for MTK_NETSYS_V2
        MAINTAINERS: rectify file entry in BONDING DRIVER
        i40e: Fix incorrect address type for IPv6 flow rules
        ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter
        net: Fix a data-race around sysctl_somaxconn.
        net: Fix a data-race around netdev_unregister_timeout_secs.
        net: Fix a data-race around gro_normal_batch.
        net: Fix data-races around sysctl_devconf_inherit_init_net.
        net: Fix data-races around sysctl_fb_tunnels_only_for_init_net.
        net: Fix a data-race around netdev_budget_usecs.
        net: Fix data-races around sysctl_max_skb_frags.
        net: Fix a data-race around netdev_budget.
        ...
      4c612826
    • Jakub Kicinski's avatar
      Merge branch 'net-lantiq_xrx200-fix-errors-under-memory-pressure' · d974730c
      Jakub Kicinski authored
      Aleksander Jan Bajkowski says:
      
      ====================
      net: lantiq_xrx200: fix errors under memory pressure
      
      This series fixes issues that can occur in the driver under memory pressure.
      Situations when the system cannot allocate memory are rare, so the mentioned
      bugs have been fixed recently. The patches have been tested on a BT Home
      router with the Lantiq xRX200 chipset.
      
      Changelog:
        v3: - removed netdev_err() log from the first patch
        v2:
         - the second patch has been changed, so that under memory pressure situation
           the driver will not receive packets indefinitely regardless of the NAPI budget,
         - the third patch has been added.
      ====================
      
      Link: https://lore.kernel.org/r/20220824215408.4695-1-olek2@wp.pl
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d974730c
    • Aleksander Jan Bajkowski's avatar
      net: lantiq_xrx200: restore buffer if memory allocation failed · c9c3b177
      Aleksander Jan Bajkowski authored
      In a situation where memory allocation fails, an invalid buffer address
      is stored. When this descriptor is used again, the system panics in the
      build_skb() function when accessing memory.
      
      Fixes: 7ea6cd16
      
       ("lantiq: net: fix duplicated skb in rx descriptor ring")
      Signed-off-by: default avatarAleksander Jan Bajkowski <olek2@wp.pl>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c9c3b177
    • Aleksander Jan Bajkowski's avatar
      net: lantiq_xrx200: fix lock under memory pressure · c4b6e934
      Aleksander Jan Bajkowski authored
      When the xrx200_hw_receive() function returns -ENOMEM, the NAPI poll
      function immediately returns an error.
      This is incorrect for two reasons:
      * the function terminates without enabling interrupts or scheduling NAPI,
      * the error code (-ENOMEM) is returned instead of the number of received
      packets.
      
      After the first memory allocation failure occurs, packet reception is
      locked due to disabled interrupts from DMA..
      
      Fixes: fe1a5642
      
       ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver")
      Signed-off-by: default avatarAleksander Jan Bajkowski <olek2@wp.pl>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c4b6e934
    • Aleksander Jan Bajkowski's avatar
      net: lantiq_xrx200: confirm skb is allocated before using · c8b04370
      Aleksander Jan Bajkowski authored
      xrx200_hw_receive() assumes build_skb() always works and goes straight
      to skb_reserve(). However, build_skb() can fail under memory pressure.
      
      Add a check in case build_skb() failed to allocate and return NULL.
      
      Fixes: e0155935
      
       ("net: lantiq_xrx200: convert to build_skb")
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarAleksander Jan Bajkowski <olek2@wp.pl>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c8b04370
    • Heiner Kallweit's avatar
      net: stmmac: work around sporadic tx issue on link-up · a3a57bf0
      Heiner Kallweit authored
      This is a follow-up to the discussion in [0]. It seems to me that
      at least the IP version used on Amlogic SoC's sometimes has a problem
      if register MAC_CTRL_REG is written whilst the chip is still processing
      a previous write. But that's just a guess.
      Adding a delay between two writes to this register helps, but we can
      also simply omit the offending second write. This patch uses the second
      approach and is based on a suggestion from Qi Duan.
      Benefit of this approach is that we can save few register writes, also
      on not affected chip versions.
      
      [0] https://www.spinics.net/lists/netdev/msg831526.html
      
      Fixes: bfab27a1
      
       ("stmmac: add the experimental PCI support")
      Suggested-by: default avatarQi Duan <qi.duan@amlogic.com>
      Suggested-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Link: https://lore.kernel.org/r/e99857ce-bd90-5093-ca8c-8cd480b5a0a2@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a3a57bf0
    • Jakub Kicinski's avatar
      Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · ef332fe1
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2022-08-24 (ixgbe, i40e)
      
      This series contains updates to ixgbe and i40e drivers.
      
      Jake stops incorrect resetting of SYSTIME registers when starting
      cyclecounter for ixgbe.
      
      Sylwester corrects a check on source IP address when validating destination
      for i40e.
      
      * '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
        i40e: Fix incorrect address type for IPv6 flow rules
        ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter
      ====================
      
      Link: https://lore.kernel.org/r/20220824193748.874343-1-anthony.l.nguyen@intel.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ef332fe1
    • Jakub Kicinski's avatar
      Merge branch 'ionic-bug-fixes' · 92df825a
      Jakub Kicinski authored
      Shannon Nelson says:
      
      ====================
      ionic: bug fixes
      
      These are a couple of maintenance bug fixes for the Pensando ionic
      networking driver.
      
      Mohamed takes care of a "plays well with others" issue where the
      VF spec is a bit vague on VF mac addresses, but certain customers
      have come to expect behavior based on other vendor drivers.
      
      Shannon addresses a couple of corner cases seen in internal
      stress testing.
      ====================
      
      Link: https://lore.kernel.org/r/20220824165051.6185-1-snelson@pensando.io
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      92df825a
    • R Mohamed Shah's avatar
      ionic: VF initial random MAC address if no assigned mac · 19058be7
      R Mohamed Shah authored
      Assign a random mac address to the VF interface station
      address if it boots with a zero mac address in order to match
      similar behavior seen in other VF drivers.  Handle the errors
      where the older firmware does not allow the VF to set its own
      station address.
      
      Newer firmware will allow the VF to set the station mac address
      if it hasn't already been set administratively through the PF.
      Setting it will also be allowed if the VF has trust.
      
      Fixes: fbb39807
      
       ("ionic: support sr-iov operations")
      Signed-off-by: default avatarR Mohamed Shah <mohamed@pensando.io>
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      19058be7
    • Shannon Nelson's avatar
      ionic: fix up issues with handling EAGAIN on FW cmds · 0fc4dd45
      Shannon Nelson authored
      In looping on FW update tests we occasionally see the
      FW_ACTIVATE_STATUS command fail while it is in its EAGAIN loop
      waiting for the FW activate step to finsh inside the FW.  The
      firmware is complaining that the done bit is set when a new
      dev_cmd is going to be processed.
      
      Doing a clean on the cmd registers and doorbell before exiting
      the wait-for-done and cleaning the done bit before the sleep
      prevents this from occurring.
      
      Fixes: fbfb8031
      
       ("ionic: Add hardware init and device commands")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0fc4dd45
    • Shannon Nelson's avatar
      ionic: clear broken state on generation change · 9cb9dadb
      Shannon Nelson authored
      There is a case found in heavy testing where a link flap happens just
      before a firmware Recovery event and the driver gets stuck in the
      BROKEN state.  This comes from the driver getting interrupted by a FW
      generation change when coming back up from the link flap, and the call
      to ionic_start_queues() in ionic_link_status_check() fails.  This can be
      addressed by having the fw_up code clear the BROKEN bit if seen, rather
      than waiting for a user to manually force the interface down and then
      back up.
      
      Fixes: 9e8eaf84
      
       ("ionic: stop watchdog when in broken state")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9cb9dadb
    • David Howells's avatar
      rxrpc: Fix locking in rxrpc's sendmsg · b0f571ec
      David Howells authored
      Fix three bugs in the rxrpc's sendmsg implementation:
      
       (1) rxrpc_new_client_call() should release the socket lock when returning
           an error from rxrpc_get_call_slot().
      
       (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex
           held in the event that we're interrupted by a signal whilst waiting
           for tx space on the socket or relocking the call mutex afterwards.
      
           Fix this by: (a) moving the unlock/lock of the call mutex up to
           rxrpc_send_data() such that the lock is not held around all of
           rxrpc_wait_for_tx_window*() and (b) indicating to higher callers
           whether we're return with the lock dropped.  Note that this means
           recvmsg() will not block on this call whilst we're waiting.
      
       (3) After dropping and regaining the call mutex, rxrpc_send_data() needs
           to go and recheck the state of the tx_pending buffer and the
           tx_total_len check in case we raced with another sendmsg() on the same
           call.
      
      Thinking on this some more, it might make sense to have different locks for
      sendmsg() and recvmsg().  There's probably no need to make recvmsg() wait
      for sendmsg().  It does mean that recvmsg() can return MSG_EOR indicating
      that a call is dead before a sendmsg() to that call returns - but that can
      currently happen anyway.
      
      Without fix (2), something like the following can be induced:
      
      	WARNING: bad unlock balance detected!
      	5.16.0-rc6-syzkaller #0 Not tainted
      	-------------------------------------
      	syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
      	[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
      	but there are no more locks to release!
      
      	other info that might help us debug this:
      	no locks held by syz-executor011/3597.
      	...
      	Call Trace:
      	 <TASK>
      	 __dump_stack lib/dump_stack.c:88 [inline]
      	 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
      	 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
      	 __lock_release kernel/locking/lockdep.c:5306 [inline]
      	 lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
      	 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900
      	 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
      	 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561
      	 sock_sendmsg_nosec net/socket.c:704 [inline]
      	 sock_sendmsg+0xcf/0x120 net/socket.c:724
      	 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
      	 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
      	 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
      	 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
      
      [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]
      
      Fixes: bc5e3a54
      
       ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
      Reported-by: default avatar <syzbot+7f0483225d0c94cb3441@syzkaller.appspotmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Tested-by: default avatar <syzbot+7f0483225d0c94cb3441@syzkaller.appspotmail.com>
      cc: Hawkins Jiawei <yin31149@gmail.com>
      cc: Khalid Masum <khalid.masum.92@gmail.com>
      cc: Dan Carpenter <dan.carpenter@oracle.com>
      cc: linux-afs@lists.infradead.org
      Link: https://lore.kernel.org/r/166135894583.600315.7170979436768124075.stgit@warthog.procyon.org.uk
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b0f571ec
    • Linus Torvalds's avatar
      Merge tag 'cgroup-for-6.0-rc2-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · 3f5c2005
      Linus Torvalds authored
      Pull another cgroup fix from Tejun Heo:
       "Commit 4f7e7236 ("cgroup: Fix threadgroup_rwsem <->
        cpus_read_lock() deadlock") required the cgroup
        core to grab cpus_read_lock() before invoking ->attach().
      
        Unfortunately, it missed adding cpus_read_lock() in
        cgroup_attach_task_all(). Fix it"
      
      * tag 'cgroup-for-6.0-rc2-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
        cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
      3f5c2005
    • Tetsuo Handa's avatar
      cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all() · 43626dad
      Tetsuo Handa authored
      syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at
      cpuset_attach() [1], for commit 4f7e7236 ("cgroup: Fix
      threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that
      cpuset_attach() is also called from cgroup_attach_task_all().
      Add cpus_read_lock() like what cgroup_procs_write_start() does.
      
      Link: https://syzkaller.appspot.com/bug?extid=29d3a3b4d86c8136ad9e
      
       [1]
      Reported-by: default avatarsyzbot <syzbot+29d3a3b4d86c8136ad9e@syzkaller.appspotmail.com>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Fixes: 4f7e7236
      
       ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock")
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      43626dad
  3. Aug 25, 2022
  4. Aug 24, 2022