- 28 Jan, 2021 5 commits
-
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-5.11-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-01-27 The patch is by Dan Carpenter and fixes a potential information leak in can_fill_info(). * tag 'linux-can-fixes-for-5.11-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: dev: prevent potential information leak in can_fill_info() ==================== Link: https://lore.kernel.org/r/20210127094028.2778793-1-mkl@pengutronix.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
include/net/bonding.h is missing from bonding entry. Link: https://lore.kernel.org/r/20210127021844.4071706-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Anthony Nguyen says: ==================== Intel Wired LAN Driver Updates 2021-01-26 This series contains updates to the ice, i40e, and igc driver. Henry corrects setting an unspecified protocol to IPPROTO_NONE instead of 0 for IPv6 flexbytes filters for ice. Nick fixes the IPv6 extension header being processed incorrectly and updates the netdev->dev_addr if it exists in hardware as it may have been modified outside the ice driver. Brett ensures a user cannot request more channels than available LAN MSI-X and fixes the minimum allocation logic as it was incorrectly trying to use more MSI-X than allocated for ice. Stefan Assmann minimizes the delay between getting and using the VSI pointer to prevent a possible crash for i40e. Corinna Vinschen fixes link speed advertising for igc. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: fix link speed advertising i40e: acquire VSI pointer only after VF is initialized ice: Fix MSI-X vector fallback logic ice: Don't allow more channels than LAN MSI-X available ice: update dev_addr in ice_set_mac_address even if HW filter exists ice: Implement flow for IPv6 next header (extension header) ice: fix FDir IPv6 flexbyte ==================== Link: https://lore.kernel.org/r/20210126221035.658124-1-anthony.l.nguyen@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Vadim Fedorenko authored
On building the route there is an assumption that the destination could be local. In this case loopback_dev is used to get the address. If the address is still cannot be retrieved dn_route_output_slow returns EADDRNOTAVAIL with loopback_dev reference taken. Cannot find hash for the fixes tag because this code was introduced long time ago. I don't think that this bug has ever fired but the patch is done just to have a consistent code base. Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru> Link: https://lore.kernel.org/r/1611619334-20955-1-git-send-email-vfedorenko@novek.ruSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Rasmus Villemoes authored
It's not true that switchdev_port_obj_notify() only inspects the ->handled field of "struct switchdev_notifier_port_obj_info" if call_switchdev_blocking_notifiers() returns 0 - there's a WARN_ON() triggering for a non-zero return combined with ->handled not being true. But the real problem here is that -EOPNOTSUPP is not being properly handled. The wrapper functions switchdev_handle_port_obj_add() et al change a return value of -EOPNOTSUPP to 0, and the treatment of ->handled in switchdev_port_obj_notify() seems to be designed to change that back to -EOPNOTSUPP in case nobody actually acted on the notifier (i.e., everybody returned -EOPNOTSUPP). Currently, as soon as some device down the stack passes the check_cb() check, ->handled gets set to true, which means that switchdev_port_obj_notify() cannot actually ever return -EOPNOTSUPP. This, for example, means that the detection of hardware offload support in the MRP code is broken: switchdev_port_obj_add() used by br_mrp_switchdev_send_ring_test() always returns 0, so since the MRP code thinks the generation of MRP test frames has been offloaded, no such frames are actually put on the wire. Similarly, br_mrp_switchdev_set_ring_role() also always returns 0, causing mrp->ring_role_offloaded to be set to 1. To fix this, continue to set ->handled true if any callback returns success or any error distinct from -EOPNOTSUPP. But if all the callbacks return -EOPNOTSUPP, make sure that ->handled stays false, so the logic in switchdev_port_obj_notify() can propagate that information. Fixes: 9a9f26e8 ("bridge: mrp: Connect MRP API with the switchdev API") Fixes: f30f0601 ("switchdev: Add helpers to aid traversal through lower devices") Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Link: https://lore.kernel.org/r/20210125124116.102928-1-rasmus.villemoes@prevas.dkSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 27 Jan, 2021 6 commits
-
-
Dan Carpenter authored
The "bec" struct isn't necessarily always initialized. For example, the mcp251xfd_get_berr_counter() function doesn't initialize anything if the interface is down. Fixes: 52c793f2 ("can: netlink support for bus-error reporting and counters") Link: https://lore.kernel.org/r/YAkaRdRJncsJO8Ve@mwandaSigned-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Jakub Kicinski authored
Laurent Badel says: ==================== net: fec: Fix temporary RMII clock reset on link up v2: fixed a compilation warning The FEC drivers performs a "hardware reset" of the MAC module when the link is reported to be up. This causes a short glitch in the RMII clock due to the hardware reset clearing the receive control register which controls the MII mode. It seems that some link partners do not tolerate this glitch, and invalidate the link, which leads to a never-ending loop of negotiation-link up-link down events. This was observed with the iMX28 Soc and LAN8720/LAN8742 PHYs, with two Intel adapters I218-LM and X722-DA2 as link partners, though a number of other link partners do not seem to mind the clock glitch. Changing the hardware reset to a software reset (clearing bit 1 of the ECR register) cured the issue. Attempts to optimize fec_restart() in order to minimize the duration of the glitch were unsuccessful. Furthermore manually producing the glitch by setting MII mode and then back to RMII in two consecutive instructions, resulting in a clock glitch <10us in duration, was enough to cause the partner to invalidate the link. This strongly suggests that the root cause of the link being dropped is indeed the change in clock frequency. In an effort to minimize changes to driver, the patch proposes to use soft reset only for tested SoCs (iMX28) and only if the link is up. This preserves hardware reset in other situations, which might be required for proper setup of the MAC. ==================== Link: https://lore.kernel.org/r/20210125100745.5090-1-laurentbadel@eaton.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Laurent Badel authored
fec_restart() does a hard reset of the MAC module when the link status changes to up. This temporarily resets the R_CNTRL register which controls the MII mode of the ENET_OUT clock. In the case of RMII, the clock frequency momentarily drops from 50MHz to 25MHz until the register is reconfigured. Some link partners do not tolerate this glitch and invalidate the link causing failure to establish a stable link when using PHY polling mode. Since as per IEEE802.3 the criteria for link validity are PHY-specific, what the partner should tolerate cannot be assumed, so avoid resetting the MII clock by using software reset instead of hardware reset when the link is up. This is generally relevant only if the SoC provides the clock to an external PHY and the PHY is configured for RMII. Signed-off-by: Laurent Badel <laurentbadel@eaton.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Xie He authored
In the lapb module, the timers may run concurrently with other code in this module, and there is currently no locking to prevent the code from racing on "struct lapb_cb". This patch adds locking to prevent racing. 1. Add "spinlock_t lock" to "struct lapb_cb"; Add "spin_lock_bh" and "spin_unlock_bh" to APIs, timer functions and notifier functions. 2. Add "bool t1timer_stop, t2timer_stop" to "struct lapb_cb" to make us able to ask running timers to abort; Modify "lapb_stop_t1timer" and "lapb_stop_t2timer" to make them able to abort running timers; Modify "lapb_t2timer_expiry" and "lapb_t1timer_expiry" to make them abort after they are stopped by "lapb_stop_t1timer", "lapb_stop_t2timer", and "lapb_start_t1timer", "lapb_start_t2timer". 3. Let lapb_unregister wait for other API functions and running timers to stop. 4. The lapb_device_event function calls lapb_disconnect_request. In order to avoid trying to hold the lock twice, add a new function named "__lapb_disconnect_request" which assumes the lock is held, and make it called by lapb_disconnect_request and lapb_device_event. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20210126040939.69995-1-xie.he.0141@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Ivan Vecera authored
Function __team_compute_features() is protected by team->lock mutex when it is called from team_compute_features() used when features of an underlying device is changed. This causes a deadlock when NETDEV_FEAT_CHANGE notifier for underlying device is fired due to change propagated from team driver (e.g. MTU change). It's because callbacks like team_change_mtu() or team_vlan_rx_{add,del}_vid() protect their port list traversal by team->lock mutex. Example (r8169 case where this driver disables TSO for certain MTU values): ... [ 6391.348202] __mutex_lock.isra.6+0x2d0/0x4a0 [ 6391.358602] team_device_event+0x9d/0x160 [team] [ 6391.363756] notifier_call_chain+0x47/0x70 [ 6391.368329] netdev_update_features+0x56/0x60 [ 6391.373207] rtl8169_change_mtu+0x14/0x50 [r8169] [ 6391.378457] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.387022] dev_set_mtu+0x52/0x90 [ 6391.390820] team_change_mtu+0x64/0xf0 [team] [ 6391.395683] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.399963] do_setlink+0x231/0xf50 ... In fact team_compute_features() called from team_device_event() does not need to be protected by team->lock mutex and rcu_read_lock() is sufficient there for port list traversal. Fixes: 3d249d4c ("net: introduce ethernet teaming device") Cc: Saeed Mahameed <saeed@kernel.org> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20210125074416.4056484-1-ivecera@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
David has been the de-facto maintainer for much of the IP code for the last couple of years, let's make it official. Link: https://lore.kernel.org/r/20210122173220.3579491-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 26 Jan, 2021 13 commits
-
-
Jakub Kicinski authored
Merge tag 'mac80211-for-net-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A couple of fixes: * fix 160 MHz channel switch in mac80211 * fix a staging driver to not deadlock due to some recent cfg80211 changes * fix NULL-ptr deref if cfg80211 returns -EINPROGRESS to wext (syzbot) * pause TX in mac80211 in type change to prevent crashes (syzbot) * tag 'mac80211-for-net-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211: staging: rtl8723bs: fix wireless regulatory API misuse mac80211: pause TX while changing interface type wext: fix NULL-ptr-dereference with cfg80211's lack of commit() mac80211: 160MHz with extended NSS BW in CSA ==================== Link: https://lore.kernel.org/r/20210126130529.75225-1-johannes@sipsolutions.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'wireless-drivers-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.11 Second set of fixes for v5.11. Like in last time we again have more fixes than usual Actually a bit too much for my liking in this state of the cycle, but due to unrelated challenges I was only able to submit them now. We have few important crash fixes, iwlwifi modifying read-only data being the most reported issue, and also smaller fixes to iwlwifi. mt76 * fix a clang warning about enum usage * fix rx buffer refcounting crash mt7601u * fix rx buffer refcounting crash * fix crash when unbplugging the device iwlwifi * fix a crash where we were modifying read-only firmware data * lots of smaller fixes all over the driver * tag 'wireless-drivers-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers: (24 commits) mt7601u: fix kernel crash unplugging the device iwlwifi: queue: bail out on invalid freeing iwlwifi: mvm: guard against device removal in reprobe iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit. iwlwifi: mvm: clear IN_D3 after wowlan status cmd iwlwifi: pcie: add rules to match Qu with Hr2 iwlwifi: mvm: invalidate IDs of internal stations at mvm start iwlwifi: mvm: fix the return type for DSM functions 1 and 2 iwlwifi: pcie: reschedule in long-running memory reads iwlwifi: pcie: use jiffies for memory read spin time limit iwlwifi: pcie: fix context info memory leak iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap iwlwifi: pcie: set LTR on more devices iwlwifi: queue: don't crash if txq->entries is NULL iwlwifi: fix the NMI flow for old devices iwlwifi: pnvm: don't try to load after failures iwlwifi: pnvm: don't skip everything when not reloading iwlwifi: pcie: avoid potential PNVM leaks iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time() iwlwifi: mvm: skip power command when unbinding vif during CSA ... ==================== Link: https://lore.kernel.org/r/20210126092202.6A367C433CA@smtp.codeaurora.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
net/core/tso.c got recent support for USO, and this broke iwlfifi because the driver implemented a limited form of GSO. Providing ->gso_type allows for skb_is_gso_tcp() to provide a correct result. Fixes: 3d5b459b ("net: tso: add UDP segmentation support") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Ben Greear <greearb@candelatech.com> Tested-by: Ben Greear <greearb@candelatech.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Johannes Berg <johannes@sipsolutions.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209913 Link: https://lore.kernel.org/r/20210125150949.619309-1-eric.dumazet@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Corinna Vinschen authored
Link speed advertising in igc has two problems: - When setting the advertisement via ethtool, the link speed is converted to the legacy 32 bit representation for the intel PHY code. This inadvertently drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT (being beyond bit 31). As a result, any call to `ethtool -s ...' drops the 2500Mbit/s link speed from the PHY settings. Only reloading the driver alleviates that problem. Fix this by converting the ETHTOOL_LINK_MODE_2500baseT_Full_BIT to the Intel PHY ADVERTISE_2500_FULL bit explicitly. - Rather than checking the actual PHY setting, the .get_link_ksettings function always fills link_modes.advertising with all link speeds the device is capable of. Fix this by checking the PHY autoneg_advertised settings and report only the actually advertised speeds up to ethtool. Fixes: 8c5ad0da ("igc: Add ethtool support") Signed-off-by: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Stefan Assmann authored
This change simplifies the VF initialization check and also minimizes the delay between acquiring the VSI pointer and using it. As known by the commit being fixed, there is a risk of the VSI pointer getting changed. Therefore minimize the delay between getting and using the pointer. Fixes: 9889707b ("i40e: Fix crash caused by stress setting of VF MAC addresses") Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Brett Creeley authored
The current MSI-X enablement logic tries to enable best-case MSI-X vectors and if that fails we only support a bare-minimum set. This includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X for the OICR interrupt. Unfortunately, the driver fails to load when we don't get as many MSI-X as requested for a couple reasons. First, the code to allocate MSI-X in the driver tries to allocate num_online_cpus() MSI-X for LAN traffic without caring about the number of MSI-X actually enabled/requested from the kernel for LAN traffic. So, when calling ice_get_res() for the PF VSI, it returns failure because the number of available vectors is less than requested. Fix this by not allowing the PF VSI to allocation more than pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues. Limiting the number of queues is done because we don't want more than 1 Tx/Rx queue per interrupt due to performance conerns. Second, the driver assigns pf->num_lan_msix = 2, to account for LAN traffic and the OICR. However, pf->num_lan_msix is only meant for LAN MSI-X. This is causing a failure when the PF VSI tries to allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has already been reserved, so there may not be enough MSI-X vectors left. Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for the failure case. Update the related defines used in ice_ena_msix_range() to align with the above behavior and remove the unused RDMA defines because RDMA is currently not supported. Also, remove the now incorrect comment. Fixes: 152b978a ("ice: Rework ice_ena_msix_range") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Brett Creeley authored
Currently users could create more channels than LAN MSI-X available. This is happening because there is no check against pf->num_lan_msix when checking the max allowed channels and will cause performance issues if multiple Tx and Rx queues are tied to a single MSI-X. Fix this by not allowing more channels than LAN MSI-X available in pf->num_lan_msix. Fixes: 87324e74 ("ice: Implement ethtool ops for channels") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Nick Nunley authored
Fix the driver to copy the MAC address configured in ndo_set_mac_address into dev_addr, even if the MAC filter already exists in HW. In some situations (e.g. bonding) the netdev's dev_addr could have been modified outside of the driver, with no change to the HW filter, so the driver cannot assume that they match. Fixes: 757976ab ("ice: Fix check for removing/adding mac filters") Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Nick Nunley authored
This patch is based on a similar change to i40e by Slawomir Laba: "i40e: Implement flow for IPv6 next header (extension header)". When a packet contains an IPv6 header with next header which is an extension header and not a protocol one, the kernel function skb_transport_header called with such sk_buff will return a pointer to the extension header and not to the TCP one. The above explained call caused a problem with packet processing for skb with encapsulation for tunnel with ICE_TX_CTX_EIPT_IPV6. The extension header was not skipped at all. The ipv6_skip_exthdr function does check if next header of the IPV6 header is an extension header and doesn't modify the l4_proto pointer if it points to a protocol header value so its safe to omit the comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can return value -1. This means that the skipping process failed and there is something wrong with the packet so it will be dropped. Fixes: a4e82a81 ("ice: Add support for tunnel offloads") Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Henry Tieman authored
The packet classifier would occasionally misrecognize an IPv6 training packet when the next protocol field was 0. The correct value for unspecified protocol is IPPROTO_NONE. Fixes: 165d80d6 ("ice: Support IPv6 Flow Director filters") Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-
Johannes Berg authored
This code ends up calling wiphy_apply_custom_regulatory(), for which we document that it should be called before wiphy_register(). This driver doesn't do that, but calls it from ndo_open() with the RTNL held, which caused deadlocks. Since the driver just registers static regdomain data and then the notifier applies the channel changes if any, there's no reason for it to call this in ndo_open(), move it earlier to fix the deadlock. Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com> Fixes: 51d62f2f ("cfg80211: Save the regulatory domain with a lock") Link: https://lore.kernel.org/r/20210126115409.d5fd6f8fe042.Ib5823a6feb2e2aa01ca1a565d2505367f38ad246@changeidAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
syzbot reported a crash that happened when changing the interface type around a lot, and while it might have been easy to fix just the symptom there, a little deeper investigation found that really the reason is that we allowed packets to be transmitted while in the middle of changing the interface type. Disallow TX by stopping the queues while changing the type. Fixes: 34d4bc4d ("mac80211: support runtime interface type changes") Reported-by: syzbot+d7a3b15976bf7de2238a@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210122171115.b321f98f4d4f.I6997841933c17b093535c31d29355be3c0c39628@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Since cfg80211 doesn't implement commit, we never really cared about that code there (and it's configured out w/o CONFIG_WIRELESS_EXT). After all, since it has no commit, it shouldn't return -EIWCOMMIT to indicate commit is needed. However, EIWCOMMIT is actually an alias for EINPROGRESS, which _can_ happen if e.g. we try to change the frequency but we're already in the process of connecting to some network, and drivers could return that value (or even cfg80211 itself might). This then causes us to crash because dev->wireless_handlers is NULL but we try to check dev->wireless_handlers->standard[0]. Fix this by also checking dev->wireless_handlers. Also simplify the code a little bit. Cc: stable@vger.kernel.org Reported-by: syzbot+444248c79e117bc99f46@syzkaller.appspotmail.com Reported-by: syzbot+8b2a88a09653d4084179@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210121171621.2076e4a37d5a.I5d9c72220fe7bb133fb718751da0180a57ecba4e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 25 Jan, 2021 16 commits
-
-
Justin Iurman authored
Following RFC 6554 [1], the current order of fields is wrong for big endian definition. Indeed, here is how the header looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmprI | CmprE | Pad | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This patch reorders fields so that big endian definition is now correct. [1] https://tools.ietf.org/html/rfc6554#section-3 Fixes: cfa933d9 ("include: uapi: linux: add rpl sr header definition") Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Lorenzo Bianconi authored
The following crash log can occur unplugging the usb dongle since, after the urb poison in mt7601u_free_tx_queue(), usb_submit_urb() will always fail resulting in a skb kfree while the skb has been already queued. Fix the issue enqueuing the skb only if usb_submit_urb() succeed. Hardware name: Hewlett-Packard 500-539ng/2B2C, BIOS 80.06 04/01/2015 Workqueue: usb_hub_wq hub_event RIP: 0010:skb_trim+0x2c/0x30 RSP: 0000:ffffb4c88005bba8 EFLAGS: 00010206 RAX: 000000004ad483ee RBX: ffff9a236625dee0 RCX: 000000000000662f RDX: 000000000000000c RSI: 0000000000000000 RDI: ffff9a2343179300 RBP: ffff9a2343179300 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9a23748f7840 R11: 0000000000000001 R12: ffff9a236625e4d4 R13: ffff9a236625dee0 R14: 0000000000001080 R15: 0000000000000008 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd410a34ef8 CR3: 00000001416ee001 CR4: 00000000001706f0 Call Trace: mt7601u_tx_status+0x3e/0xa0 [mt7601u] mt7601u_dma_cleanup+0xca/0x110 [mt7601u] mt7601u_cleanup+0x22/0x30 [mt7601u] mt7601u_disconnect+0x22/0x60 [mt7601u] usb_unbind_interface+0x8a/0x270 ? kernfs_find_ns+0x35/0xd0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 bus_remove_device+0xdb/0x140 device_del+0x18b/0x430 ? kobject_put+0x98/0x1d0 usb_disable_device+0xc6/0x1f0 usb_disconnect.cold+0x7e/0x20a hub_event+0xbf3/0x1870 process_one_work+0x1b6/0x350 worker_thread+0x53/0x3e0 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Fixes: 23377c20 ("mt7601u: fix possible memory leak when the device is disconnected") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jakub Kicinski <kubakici@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/3b85219f669a63a8ced1f43686de05915a580489.1610919247.git.lorenzo@kernel.org
-
Johannes Berg authored
If we find an entry without an SKB, we currently continue, but that will just result in an infinite loop since we won't increment the read pointer, and will try the same thing over and over again. Fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.abe2dedcc3ac.Ia6b03f9eeb617fd819e56dd5376f4bb8edc7b98a@changeid
-
Johannes Berg authored
If we get into a problem severe enough to attempt a reprobe, we schedule a worker to do that. However, if the problem gets more severe and the device is actually destroyed before this worker has a chance to run, we use a free device. Bump up the reference count of the device until the worker runs to avoid this situation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.871f0892e4b2.I94819e11afd68d875f3e242b98bef724b8236f1e@changeid
-
Matti Gottlieb authored
The bit that indicates if the device supports 160MHZ is bit #9. The macro checks bit #8. Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit. Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com> Fixes: d6f2134a ("iwlwifi: add mac/rf types and 160MHz to the device tables") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.bddbf9b57a75.I16e09e2b1404b16bfff70852a5a654aa468579e2@changeid
-
Shaul Triebitz authored
In D3 resume flow, avoid the following race where sending packets before updating the sequence number (sequence number received from the wowlan status command response): Thread 1: __iwl_mvm_resume clears IWL_MVM_STATUS_IN_D3 and is cut by thread 2 before reaching iwl_mvm_query_wakeup_reasons. Thread 2: iwl_mvm_mac_itxq_xmit calls iwl_mvm_tx_skb since IWL_MVM_STATUS_IN_D3 is not set using a wrong sequence number. Thread 1: __iwl_mvm_resume continues and calls iwl_mvm_query_wakeup_reasons updating the sequence number received from the firmware. The next packet that will be sent now will cause sysassert 0x1096. Fix the bug by moving 'clear IWL_MVM_STATUS_IN_D3' to after sending the wowlan status command and updating the sequence number. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.fe927ec939c6.I103d3321fb55da7e6c6c51582cfadf94eb8b6c58@changeid
-
Luca Coelho authored
Until now we have been relying on matching the PCI ID and subsystem device ID in order to recognize Qu devices with Hr2. Add rules to match these devices, so that we don't have to add a new rule for every new ID we get. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.591ce253ddd8.Ia4b9cc2c535625890c6d6b560db97ee9f2d5ca3b@changeid
-
Gregory Greenman authored
Having sta_id not set for aux_sta and snif_sta can potentially lead to a hard to debug issue in case remove station is called without an add. In this case sta_id 0, an unrelated regular station, will be removed. In fact, we do have a FW assert that occures rarely and from the debug data analysis it looks like sta_id 0 is removed by mistake, though it's hard to pinpoint the exact flow. The WARN_ON in this patch should help to find it. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.5dc6dd9b22d5.I2add1b5ad24d0d0a221de79d439c09f88fcaf15d@changeid
-
Matt Chen authored
The return type value of functions 1 and 2 were considered to be an integer inside a buffer, but they can also be only an integer, without the buffer. Fix the code in iwl_acpi_get_dsm_u8() to handle it as a single integer value, as well as packed inside a buffer. Signed-off-by: Matt Chen <matt.chen@intel.com> Fixes: 9db93491 ("iwlwifi: acpi: support device specific method (DSM)") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210122144849.5757092adcd6.Ic24524627b899c9a01af38107a62a626bdf5ae3a@changeid
-
Johannes Berg authored
If we spin for a long time in memory reads that (for some reason in hardware) take a long time, then we'll eventually get messages such as watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/2:2:272] This is because the reading really does take a very long time, and we don't schedule, so we're hogging the CPU with this task, at least if CONFIG_PREEMPT is not set, e.g. with CONFIG_PREEMPT_VOLUNTARY=y. Previously I misinterpreted the situation and thought that this was only going to happen if we had interrupts disabled, and then fixed this (which is good anyway, however), but that didn't always help; looking at it again now I realized that the spin unlock will only reschedule if CONFIG_PREEMPT is used. In order to avoid this issue, change the code to cond_resched() if we've been spinning for too long here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 04516706 ("iwlwifi: pcie: limit memory read spin time") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.217a9d6a6a12.If964cb582ab0aaa94e81c4ff3b279eaafda0fd3f@changeid
-
Johannes Berg authored
There's no reason to use ktime_get() since we don't need any better precision than jiffies, and since we no longer disable interrupts around this code (when grabbing NIC access), jiffies will work fine. Use jiffies instead of ktime_get(). This cleanup is preparation for the following patch "iwlwifi: pcie: reschedule in long-running memory reads". The code gets simpler with the weird clock use etc. removed before we add cond_resched(). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130253.621c948b1fad.I3ee9f4bc4e74a0c9125d42fb7c35cd80df4698a1@changeid
-
Johannes Berg authored
If the image loader allocation fails, we leak all the previously allocated memory. Fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.97172cbaa67c.I3473233d0ad01a71aa9400832fb2b9f494d88a11@changeid
-
Emmanuel Grumbach authored
I hit a NULL pointer exception in this function when the init flow went really bad. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.2e8da9f2c132.I0234d4b8ddaf70aaa5028a20c863255e05bc1f84@changeid
-
Johannes Berg authored
To avoid completion timeouts during device boot, set up the LTR timeouts on more devices - similar to what we had before for AX210. This also corrects the AX210 workaround to be done only on discrete (non-integrated) devices, otherwise the registers have no effect. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: edb62520 ("iwlwifi: pcie: set LTR to avoid completion timeout") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.fb819e19530b.I0396f82922db66426f52fbb70d32a29c8fd66951@changeid
-
Emmanuel Grumbach authored
The code was really awkward, we would first dereference txq->entries when calling iwl_txq_genX_tfd_unmap and then we would check that txq->entries is non-NULL. Fix that by exiting if txq->entries is NULL. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.173359fc236d.I75c7c2397d20df8d7fbc24cb16a5232d5c551889@changeid
-
Emmanuel Grumbach authored
I noticed that the flow that triggers an NMI on the firmware for old devices (tested on 7265) doesn't work. Apparently, the firmware / device is still in low power when we write the register that triggers the NMI. We call the "grab_nic_access" function to make sure the device is awake but that wasn't enough. I played with this and noticed that if we wait 1 ms after the device reports it is awake before we write to the NMI register, the device always sees our write and the firmware gets properly asserted. Triggering an NMI to the firmware can be done with the debugfs hook: echo 1 > /sys/kernel/debug/iwlwifi/0000\:00\:03.0/iwlmvm/fw_nmi What happened before is that the firmware would just stall without running its NMI routine. Because of that the driver wouldn't get the "firmware crashed" interrupt. After a while the driver would notice that the firmware is not responding to some command and it would read the error data from the firmware, but this data is populated in the NMI service routine in the firmware which was not called. So in the logs it looked like: iwlwifi 0000:00:03.0: Error sending REPLY_ERROR: time out after 2000ms. iwlwifi 0000:00:03.0: Current CMD queue read_ptr 33 write_ptr 34 iwlwifi 0000:00:03.0: Loaded firmware version: 29.09bd31e1.0 7265D-29.ucode iwlwifi 0000:00:03.0: 0x00000000 | ADVANCED_SYSASSERT iwlwifi 0000:00:03.0: 0x00000000 | trm_hw_status0 iwlwifi 0000:00:03.0: 0x00000000 | trm_hw_status1 iwlwifi 0000:00:03.0: 0x00000000 | branchlink2 iwlwifi 0000:00:03.0: 0x00000000 | interruptlink1 iwlwifi 0000:00:03.0: 0x00000000 | interruptlink2 iwlwifi 0000:00:03.0: 0x00000000 | data1 iwlwifi 0000:00:03.0: 0x00000000 | data2 iwlwifi 0000:00:03.0: 0x00000000 | data3 iwlwifi 0000:00:03.0: 0x00000000 | beacon time iwlwifi 0000:00:03.0: 0x00000000 | tsf low ... With this fix, immediately after we trigger the NMI to the firmware, we get the expected: iwlwifi 0000:00:03.0: Microcode SW error detected. Restarting 0x2000000. iwlwifi 0000:00:03.0: Start IWL Error Log Dump: iwlwifi 0000:00:03.0: Status: 0x00000040, count: 6 iwlwifi 0000:00:03.0: Loaded firmware version: 29.09bd31e1.0 7265D-29.ucode iwlwifi 0000:00:03.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN iwlwifi 0000:00:03.0: 0x000002F1 | trm_hw_status0 iwlwifi 0000:00:03.0: 0x00000000 | trm_hw_status1 iwlwifi 0000:00:03.0: 0x00043D6C | branchlink2 iwlwifi 0000:00:03.0: 0x0004AFD6 | interruptlink1 iwlwifi 0000:00:03.0: 0x000008C4 | interruptlink2 iwlwifi 0000:00:03.0: 0x00000000 | data1 iwlwifi 0000:00:03.0: 0x00000080 | data2 iwlwifi 0000:00:03.0: 0x07030000 | data3 iwlwifi 0000:00:03.0: 0x003FD4C3 | beacon time iwlwifi 0000:00:03.0: 0x00C22AC3 | tsf low iwlwifi 0000:00:03.0: 0x00000000 | tsf hi iwlwifi 0000:00:03.0: 0x00000000 | time gp1 iwlwifi 0000:00:03.0: 0x00C22AC3 | time gp2 iwlwifi 0000:00:03.0: 0x00000001 | uCode revision type iwlwifi 0000:00:03.0: 0x0000001D | uCode version major Notice the first line: "Microcode SW error detected:" which is printed in the driver's ISR, which means that the driver actually got an interrupt from the firmware saying that it crashed. And then we have the properly populated error data. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210115130252.70e67cc75d88.I6615cad4361862e7f3c9f2d3cafb6a8c61e16781@changeid
-