1. 08 Apr, 2021 9 commits
    • Johannes Berg's avatar
      nl80211: fix beacon head validation · 9a6847ba
      Johannes Berg authored
      If the beacon head attribute (NL80211_ATTR_BEACON_HEAD)
      is too short to even contain the frame control field,
      we access uninitialized data beyond the buffer. Fix this
      by checking the minimal required size first. We used to
      do this until S1G support was added, where the fixed
      data portion has a different size.
      
      Reported-and-tested-by: syzbot+72b99dcf4607e8c770f3@syzkaller.appspotmail.com
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Fixes: 1d47f119 ("nl80211: correctly validate S1G beacon head")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Link: https://lore.kernel.org/r/20210408154518.d9b06d39b4ee.Iff908997b2a4067e8d456b3cb96cab9771d252b8@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9a6847ba
    • Johannes Berg's avatar
      nl80211: fix potential leak of ACL params · abaf94ec
      Johannes Berg authored
      In case nl80211_parse_unsol_bcast_probe_resp() results in an
      error, need to "goto out" instead of just returning to free
      possibly allocated data.
      
      Fixes: 7443dcd1 ("nl80211: Unsolicited broadcast probe response support")
      Link: https://lore.kernel.org/r/20210408142833.d8bc2e2e454a.If290b1ba85789726a671ff0b237726d4851b5b0f@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      abaf94ec
    • Johannes Berg's avatar
      cfg80211: check S1G beacon compat element length · b5ac0146
      Johannes Berg authored
      We need to check the length of this element so that we don't
      access data beyond its end. Fix that.
      
      Fixes: 9eaffe50 ("cfg80211: convert S1G beacon to scan results")
      Link: https://lore.kernel.org/r/20210408142826.f6f4525012de.I9fdeff0afdc683a6024e5ea49d2daa3cd2459d11@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b5ac0146
    • A. Cody Schuffelen's avatar
      virt_wifi: Return micros for BSS TSF values · b57aa17f
      A. Cody Schuffelen authored
      cfg80211_inform_bss expects to receive a TSF value, but is given the
      time since boot in nanoseconds. TSF values are expected to be at
      microsecond scale rather than nanosecond scale.
      Signed-off-by: default avatarA. Cody Schuffelen <schuffelen@google.com>
      Link: https://lore.kernel.org/r/20210318200419.1421034-1-schuffelen@google.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b57aa17f
    • Du Cheng's avatar
      cfg80211: remove WARN_ON() in cfg80211_sme_connect · 1b5ab825
      Du Cheng authored
      A WARN_ON(wdev->conn) would trigger in cfg80211_sme_connect(), if multiple
      send_msg(NL80211_CMD_CONNECT) system calls are made from the userland, which
      should be anticipated and handled by the wireless driver. Remove this WARN_ON()
      to prevent kernel panic if kernel is configured to "panic_on_warn".
      
      Bug reported by syzbot.
      
      Reported-by: syzbot+5f9392825de654244975@syzkaller.appspotmail.com
      Signed-off-by: default avatarDu Cheng <ducheng2@gmail.com>
      Link: https://lore.kernel.org/r/20210407162756.6101-1-ducheng2@gmail.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1b5ab825
    • Ben Greear's avatar
      mac80211: fix time-is-after bug in mlme · 7d73cd94
      Ben Greear authored
      The incorrect timeout check caused probing to happen when it did
      not need to happen.  This in turn caused tx performance drop
      for around 5 seconds in ath10k-ct driver.  Possibly that tx drop
      is due to a secondary issue, but fixing the probe to not happen
      when traffic is running fixes the symptom.
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Fixes: 9abf4e49 ("mac80211: optimize station connection monitor")
      Acked-by: default avatarFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20210330230749.14097-1-greearb@candelatech.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7d73cd94
    • Johannes Berg's avatar
      mac80211: fix TXQ AC confusion · 1153a747
      Johannes Berg authored
      Normally, TXQs have
      
        txq->tid = tid;
        txq->ac = ieee80211_ac_from_tid(tid);
      
      However, the special management TXQ actually has
      
        txq->tid = IEEE80211_NUM_TIDS; // 16
        txq->ac = IEEE80211_AC_VO;
      
      This makes sense, but ieee80211_ac_from_tid(16) is the same
      as ieee80211_ac_from_tid(0) which is just IEEE80211_AC_BE.
      
      Now, normally this is fine. However, if the netdev queues
      were stopped, then the code in ieee80211_tx_dequeue() will
      propagate the stop from the interface (vif->txqs_stopped[])
      if the AC 2 (ieee80211_ac_from_tid(txq->tid)) is marked as
      stopped. On wake, however, __ieee80211_wake_txqs() will wake
      the TXQ if AC 0 (txq->ac) is woken up.
      
      If a driver stops all queues with ieee80211_stop_tx_queues()
      and then wakes them again with ieee80211_wake_tx_queues(),
      the ieee80211_wake_txqs() tasklet will run to resync queue
      and TXQ state. If all queues were woken, then what'll happen
      is that _ieee80211_wake_txqs() will run in order of HW queues
      0-3, typically (and certainly for iwlwifi) corresponding to
      ACs 0-3, so it'll call __ieee80211_wake_txqs() for each AC in
      order 0-3.
      
      When __ieee80211_wake_txqs() is called for AC 0 (VO) that'll
      wake up the management TXQ (remember its tid is 16), and the
      driver's wake_tx_queue() will be called. That tries to get a
      frame, which will immediately *stop* the TXQ again, because
      now we check against AC 2, and AC 2 hasn't yet been marked as
      woken up again in sdata->vif.txqs_stopped[] since we're only
      in the __ieee80211_wake_txqs() call for AC 0.
      
      Thus, the management TXQ will never be started again.
      
      Fix this by checking txq->ac directly instead of calculating
      the AC as ieee80211_ac_from_tid(txq->tid).
      
      Fixes: adf8ed01 ("mac80211: add an optional TXQ for other PS-buffered frames")
      Acked-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Link: https://lore.kernel.org/r/20210323210500.bf4d50afea4a.I136ffde910486301f8818f5442e3c9bf8670a9c4@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1153a747
    • Johannes Berg's avatar
      rfkill: revert back to old userspace API by default · 71826654
      Johannes Berg authored
      Recompiling with the new extended version of struct rfkill_event
      broke systemd in *two* ways:
       - It used "sizeof(struct rfkill_event)" to read the event, but
         then complained if it actually got something != 8, this broke
         it on new kernels (that include the updated API);
       - It used sizeof(struct rfkill_event) to write a command, but
         didn't implement the intended expansion protocol where the
         kernel returns only how many bytes it accepted, and errored
         out due to the unexpected smaller size on kernels that didn't
         include the updated API.
      
      Even though systemd has now been fixed, that fix may not be always
      deployed, and other applications could potentially have similar
      issues.
      
      As such, in the interest of avoiding regressions, revert the
      default API "struct rfkill_event" back to the original size.
      
      Instead, add a new "struct rfkill_event_ext" that extends it by
      the new field, and even more clearly document that applications
      should be prepared for extensions in two ways:
       * write might only accept fewer bytes on older kernels, and
         will return how many to let userspace know which data may
         have been ignored;
       * read might return anything between 8 (the original size) and
         whatever size the application sized its buffer at, indicating
         how much event data was supported by the kernel.
      
      Perhaps that will help avoid such issues in the future and we
      won't have to come up with another version of the struct if we
      ever need to extend it again.
      
      Applications that want to take advantage of the new field will
      have to be modified to use struct rfkill_event_ext instead now,
      which comes with the danger of them having already been updated
      to use it from 'struct rfkill_event', but I found no evidence
      of that, and it's still relatively new.
      
      Cc: stable@vger.kernel.org # 5.11
      Reported-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-r4 (x86-64)
      Link: https://lore.kernel.org/r/20210319232510.f1a139cfdd9c.Ic5c7c9d1d28972059e132ea653a21a427c326678@changeidSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      71826654
    • Seevalamuthu Mariappan's avatar
      mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN · dd0b4553
      Seevalamuthu Mariappan authored
      In some race conditions, with more clients and traffic configuration,
      below crash is seen when making the interface down. sta->fast_rx wasn't
      cleared when STA gets removed from 4-addr AP_VLAN interface. The crash is
      due to try accessing 4-addr AP_VLAN interface's net_device (fast_rx->dev)
      which has been deleted already.
      
      Resolve this by clearing sta->fast_rx pointer when STA removes
      from a 4-addr VLAN.
      
      [  239.449529] Unable to handle kernel NULL pointer dereference at virtual address 00000004
      [  239.449531] pgd = 80204000
      ...
      [  239.481496] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.60 #227
      [  239.481591] Hardware name: Generic DT based system
      [  239.487665] task: be05b700 ti: be08e000 task.ti: be08e000
      [  239.492360] PC is at get_rps_cpu+0x2d4/0x31c
      [  239.497823] LR is at 0xbe08fc54
      ...
      [  239.778574] [<80739740>] (get_rps_cpu) from [<8073cb10>] (netif_receive_skb_internal+0x8c/0xac)
      [  239.786722] [<8073cb10>] (netif_receive_skb_internal) from [<8073d578>] (napi_gro_receive+0x48/0xc4)
      [  239.795267] [<8073d578>] (napi_gro_receive) from [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames+0xbcc/0x12d4 [mac80211])
      [  239.804776] [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames [mac80211]) from [<c7b84d4c>] (ieee80211_rx_napi+0x7b8/0x8c8 [mac8
                  0211])
      [  239.815857] [<c7b84d4c>] (ieee80211_rx_napi [mac80211]) from [<c7f63d7c>] (ath11k_dp_process_rx+0x7bc/0x8c8 [ath11k])
      [  239.827757] [<c7f63d7c>] (ath11k_dp_process_rx [ath11k]) from [<c7f5b6c4>] (ath11k_dp_service_srng+0x2c0/0x2e0 [ath11k])
      [  239.838484] [<c7f5b6c4>] (ath11k_dp_service_srng [ath11k]) from [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll+0x20/0x84 [ath11k_ahb]
                  )
      [  239.849419] [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll [ath11k_ahb]) from [<8073ce1c>] (net_rx_action+0xe0/0x28c)
      [  239.860945] [<8073ce1c>] (net_rx_action) from [<80324868>] (__do_softirq+0xe4/0x228)
      [  239.871269] [<80324868>] (__do_softirq) from [<80324c48>] (irq_exit+0x98/0x108)
      [  239.879080] [<80324c48>] (irq_exit) from [<8035c59c>] (__handle_domain_irq+0x90/0xb4)
      [  239.886114] [<8035c59c>] (__handle_domain_irq) from [<8030137c>] (gic_handle_irq+0x50/0x94)
      [  239.894100] [<8030137c>] (gic_handle_irq) from [<803024c0>] (__irq_svc+0x40/0x74)
      Signed-off-by: default avatarSeevalamuthu Mariappan <seevalam@codeaurora.org>
      Link: https://lore.kernel.org/r/1616163532-3881-1-git-send-email-seevalam@codeaurora.orgSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      dd0b4553
  2. 07 Apr, 2021 19 commits
    • Anirudh Rayabharam's avatar
      net: hso: fix null-ptr-deref during tty device unregistration · 8a12f883
      Anirudh Rayabharam authored
      Multiple ttys try to claim the same the minor number causing a double
      unregistration of the same device. The first unregistration succeeds
      but the next one results in a null-ptr-deref.
      
      The get_free_serial_index() function returns an available minor number
      but doesn't assign it immediately. The assignment is done by the caller
      later. But before this assignment, calls to get_free_serial_index()
      would return the same minor number.
      
      Fix this by modifying get_free_serial_index to assign the minor number
      immediately after one is found to be and rename it to obtain_minor()
      to better reflect what it does. Similary, rename set_serial_by_index()
      to release_minor() and modify it to free up the minor number of the
      given hso_serial. Every obtain_minor() should have corresponding
      release_minor() call.
      
      Fixes: 72dc1c09 ("HSO: add option hso driver")
      Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com
      Tested-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAnirudh Rayabharam <mail@anirudhrb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a12f883
    • David S. Miller's avatar
      Merge tag 'ieee802154-for-davem-2021-04-07' of... · 5d1dbacd
      David S. Miller authored
      Merge tag 'ieee802154-for-davem-2021-04-07' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
      
      Stefan Schmidt says:
      
      ====================
      pull-request: ieee802154 for net 2021-04-07
      
      An update from ieee802154 for your *net* tree.
      
      Most of these are coming from the flood of syzkaller reports
      lately got for the ieee802154 subsystem. There are likely to
      come more for this, but this is a good batch to get out for now.
      
      Alexander Aring created a patchset to avoid llsec handling on a
      monitor interface, which we do not support.
      Alex Shi removed a unused macro.
      Pavel Skripkin fixed another protection fault found by syzkaller.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d1dbacd
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2021-04-07' of... · 107adc69
      David S. Miller authored
      Merge tag 'wireless-drivers-2021-04-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for v5.12
      
      Third, and last, set of fixes for v5.12. Small fixes, iwlwifi having
      most of them. brcmfmac regression caused by cfg80211 changes is the
      most important here.
      
      iwlwifi
      
      * fix a lockdep warning
      
      * fix regulatory feature detection in certain firmware versions
      
      * new hardware support
      
      * fix lockdep warning
      
      * mvm: fix beacon protection checks
      
      mt76
      
      * mt7921: fix airtime reporting
      
      brcmfmac
      
      * fix a deadlock regression
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      107adc69
    • David S. Miller's avatar
      Merge branch 'ethtool-link_mode' · 3cf14828
      David S. Miller authored
      Danielle Ratson says:
      
      ====================
      Fix link_mode derived params functionality
      
      Currently, link_mode parameter derives 3 other link parameters, speed,
      lanes and duplex, and the derived information is sent to user space.
      
      Few bugs were found in that functionality.
      First, some drivers clear the 'ethtool_link_ksettings' struct in their
      get_link_ksettings() callback and cause receiving wrong link mode
      information in user space. And also, some drivers can report random
      values in the 'link_mode' field and cause general protection fault.
      
      Second, the link parameters are only derived in netlink path so in ioctl
      path, we don't any reasonable values.
      
      Third, setting 'speed 10000 lanes 1' fails since the lanes parameter
      wasn't set for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT.
      
      Patch #1 solves the first two problems by removing link_mode parameter
      and deriving the link parameters in driver instead of ethtool.
      Patch #2 solves the third one, by setting the lanes parameter for the
      link_mode.
      
      v3:
      	* Remove the link_mode parameter in the first patch to solve
      	  both two issues from patch#1 and patch#2.
      	* Add the second patch to solve the third issue.
      
      v2:
      	* Add patch #2.
      	* Introduce 'cap_link_mode_supported' instead of adding a
      	  validity field to 'ethtool_link_ksettings' struct in patch #1.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3cf14828
    • Danielle Ratson's avatar
      ethtool: Add lanes parameter for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT · fde32dbe
      Danielle Ratson authored
      Lanes field is missing for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT
      link mode and it causes a failure when trying to set
      'speed 10000 lanes 1' on Spectrum-2 machines when autoneg is set to on.
      
      Add the lanes parameter for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT
      link mode.
      
      Fixes: c8907043 ("ethtool: Get link mode in use instead of speed and duplex parameters")
      Signed-off-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fde32dbe
    • Danielle Ratson's avatar
      ethtool: Remove link_mode param and derive link params from driver · a975d7d8
      Danielle Ratson authored
      Some drivers clear the 'ethtool_link_ksettings' struct in their
      get_link_ksettings() callback, before populating it with actual values.
      Such drivers will set the new 'link_mode' field to zero, resulting in
      user space receiving wrong link mode information given that zero is a
      valid value for the field.
      
      Another problem is that some drivers (notably tun) can report random
      values in the 'link_mode' field. This can result in a general protection
      fault when the field is used as an index to the 'link_mode_params' array
      [1].
      
      This happens because such drivers implement their set_link_ksettings()
      callback by simply overwriting their private copy of
      'ethtool_link_ksettings' struct with the one they get from the stack,
      which is not always properly initialized.
      
      Fix these problems by removing 'link_mode' from 'ethtool_link_ksettings'
      and instead have drivers call ethtool_params_from_link_mode() with the
      current link mode. The function will derive the link parameters (e.g.,
      speed) from the link mode and fill them in the 'ethtool_link_ksettings'
      struct.
      
      v3:
      	* Remove link_mode parameter and derive the link parameters in
      	  the driver instead of passing link_mode parameter to ethtool
      	  and derive it there.
      
      v2:
      	* Introduce 'cap_link_mode_supported' instead of adding a
      	  validity field to 'ethtool_link_ksettings' struct.
      
      [1]
      general protection fault, probably for non-canonical address 0xdffffc00f14cc32c: 0000 [#1] PREEMPT SMP KASAN
      KASAN: probably user-memory-access in range [0x000000078a661960-0x000000078a661967]
      CPU: 0 PID: 8452 Comm: syz-executor360 Not tainted 5.11.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__ethtool_get_link_ksettings+0x1a3/0x3a0 net/ethtool/ioctl.c:446
      Code: b7 3e fa 83 fd ff 0f 84 30 01 00 00 e8 16 b0 3e fa 48 8d 3c ed 60 d5 69 8a 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03
      +38 d0 7c 08 84 d2 0f 85 b9
      RSP: 0018:ffffc900019df7a0 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff888026136008 RCX: 0000000000000000
      RDX: 00000000f14cc32c RSI: ffffffff873439ca RDI: 000000078a661960
      RBP: 00000000ffff8880 R08: 00000000ffffffff R09: ffff88802613606f
      R10: ffffffff873439bc R11: 0000000000000000 R12: 0000000000000000
      R13: ffff88802613606c R14: ffff888011d0c210 R15: ffff888011d0c210
      FS:  0000000000749300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b60f0 CR3: 00000000185c2000 CR4: 00000000001506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       linkinfo_prepare_data+0xfd/0x280 net/ethtool/linkinfo.c:37
       ethnl_default_notify+0x1dc/0x630 net/ethtool/netlink.c:586
       ethtool_notify+0xbd/0x1f0 net/ethtool/netlink.c:656
       ethtool_set_link_ksettings+0x277/0x330 net/ethtool/ioctl.c:620
       dev_ethtool+0x2b35/0x45d0 net/ethtool/ioctl.c:2842
       dev_ioctl+0x463/0xb70 net/core/dev_ioctl.c:440
       sock_do_ioctl+0x148/0x2d0 net/socket.c:1060
       sock_ioctl+0x477/0x6a0 net/socket.c:1177
       vfs_ioctl fs/ioctl.c:48 [inline]
       __do_sys_ioctl fs/ioctl.c:753 [inline]
       __se_sys_ioctl fs/ioctl.c:739 [inline]
       __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: c8907043 ("ethtool: Get link mode in use instead of speed and duplex parameters")
      Signed-off-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a975d7d8
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2021-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · bb58023b
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2021-04-06
      
      This series provides some fixes to mlx5 driver.
      Please pull and let me know if there is any problem.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb58023b
    • Zheng Yongjun's avatar
      net: tipc: Fix spelling errors in net/tipc module · a79ace4b
      Zheng Yongjun authored
      These patches fix a series of spelling errors in net/tipc module.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZheng Yongjun <zhengyongjun3@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a79ace4b
    • Kurt Kanzenbach's avatar
      net: hsr: Reset MAC header for Tx path · 9d680392
      Kurt Kanzenbach authored
      Reset MAC header in HSR Tx path. This is needed, because direct packet
      transmission, e.g. by specifying PACKET_QDISC_BYPASS does not reset the MAC
      header.
      
      This has been observed using the following setup:
      
      |$ ip link add name hsr0 type hsr slave1 lan0 slave2 lan1 supervision 45 version 1
      |$ ifconfig hsr0 up
      |$ ./test hsr0
      
      The test binary is using mmap'ed sockets and is specifying the
      PACKET_QDISC_BYPASS socket option.
      
      This patch resolves the following warning on a non-patched kernel:
      
      |[  112.725394] ------------[ cut here ]------------
      |[  112.731418] WARNING: CPU: 1 PID: 257 at net/hsr/hsr_forward.c:560 hsr_forward_skb+0x484/0x568
      |[  112.739962] net/hsr/hsr_forward.c:560: Malformed frame (port_src hsr0)
      
      The warning can be safely removed, because the other call sites of
      hsr_forward_skb() make sure that the skb is prepared correctly.
      
      Fixes: d346a3fa ("packet: introduce PACKET_QDISC_BYPASS socket option")
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d680392
    • David S. Miller's avatar
      Merge branch 'ethtool-doc' · cd904373
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      ethtool: kdoc fixes
      
      Number of kdoc fixes to ethtool headers. All comment changes.
      
      With all the patches posted kdoc script seems happy:
      $ ./scripts/kernel-doc -none include/uapi/linux/ethtool.h include/linux/ethtool.h
      $
      
      Note that some of the changes are in -next, e.g. the FEC
      documentation update so full effect will be seen after
      trees converge.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd904373
    • Jakub Kicinski's avatar
      ethtool: fix kdoc in headers · d9c65de0
      Jakub Kicinski authored
      Fix remaining issues with kdoc in the ethtool headers.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9c65de0
    • Jakub Kicinski's avatar
      ethtool: document reserved fields in the uAPI · 83e5feeb
      Jakub Kicinski authored
      Add a note on expected handling of reserved fields,
      and references to all kdocs. This fixes a bunch
      of kdoc warnings.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83e5feeb
    • Jakub Kicinski's avatar
      ethtool: un-kdocify extended link state · f0ebc2b6
      Jakub Kicinski authored
      Extended link state structures and enums use kdoc headers
      but then do not describe any of the members.
      
      Convert to normal comments.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0ebc2b6
    • Aditya Pakki's avatar
      net/rds: Avoid potential use after free in rds_send_remove_from_sock · 0c85a7e8
      Aditya Pakki authored
      In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
      is freed and later under spinlock, causing potential use-after-free.
      Set the free pointer to NULL to avoid undefined behavior.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c85a7e8
    • Xiaoming Ni's avatar
      net/mlx5: fix kfree mismatch in indir_table.c · d5f9b005
      Xiaoming Ni authored
      Memory allocated by kvzalloc() should be freed by kvfree().
      
      Fixes: 34ca6535 ("net/mlx5: E-Switch, Indirect table infrastructur")
      Signed-off-by: default avatarXiaoming Ni <nixiaoming@huawei.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      d5f9b005
    • Aya Levin's avatar
      net/mlx5: Fix PBMC register mapping · 534b1204
      Aya Levin authored
      Add reserved mapping to cover all the register in order to avoid setting
      arbitrary values to newer FW which implements the reserved fields.
      
      Fixes: 50b4a3c2 ("net/mlx5: PPTB and PBMC register firmware command support")
      Signed-off-by: default avatarAya Levin <ayal@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      534b1204
    • Aya Levin's avatar
      net/mlx5: Fix PPLM register mapping · ce28f0fd
      Aya Levin authored
      Add reserved mapping to cover all the register in order to avoid
      setting arbitrary values to newer FW which implements the reserved
      fields.
      
      Fixes: a58837f5 ("net/mlx5e: Expose FEC feilds and related capability bit")
      Signed-off-by: default avatarAya Levin <ayal@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      ce28f0fd
    • Raed Salem's avatar
      net/mlx5: Fix placement of log_max_flow_counter · a14587df
      Raed Salem authored
      The cited commit wrongly placed log_max_flow_counter field of
      mlx5_ifc_flow_table_prop_layout_bits, align it to the HW spec intended
      placement.
      
      Fixes: 16f1c5bb ("net/mlx5: Check device capability for maximum flow counters")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      a14587df
    • Eli Cohen's avatar
      net/mlx5: Fix HW spec violation configuring uplink · 1a73704c
      Eli Cohen authored
      Make sure to modify uplink port to follow only if the uplink_follow
      capability is set as required by the HW spec. Failure to do so causes
      traffic to the uplink representor net device to cease after switching to
      switchdev mode.
      
      Fixes: 7d0314b1 ("net/mlx5e: Modify uplink state on interface up/down")
      Signed-off-by: default avatarEli Cohen <elic@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      1a73704c
  3. 06 Apr, 2021 12 commits