- 23 Dec, 2020 21 commits
-
-
Mario Limonciello authored
commit e086ba2f ("e1000e: disable s0ix entry and exit flows for ME systems") disabled s0ix flows for systems that have various incarnations of the i219-LM ethernet controller. This changed caused power consumption regressions on the following shipping Dell Comet Lake based laptops: * Latitude 5310 * Latitude 5410 * Latitude 5410 * Latitude 5510 * Precision 3550 * Latitude 5411 * Latitude 5511 * Precision 3551 * Precision 7550 * Precision 7750 This commit was introduced because of some regressions on certain Thinkpad laptops. This comment was potentially caused by an earlier commit 632fbd5e ("e1000e: fix S0ix flows for cable connected case"). or it was possibly caused by a system not meeting platform architectural requirements for low power consumption. Other changes made in the driver with extended timeouts are expected to make the driver more impervious to platform firmware behavior. Fixes: e086ba2f ("e1000e: disable s0ix entry and exit flows for ME systems") Reviewed-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
Yijun Shen <Yijun.shen@dell.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Mario Limonciello authored
Per guidance from Intel ethernet architecture team, it may take up to 1 second for unconfiguring ULP mode. However in practice this seems to be taking up to 2 seconds on some Lenovo machines. Detect scenarios that take more than 1 second but less than 2.5 seconds and emit a warning on resume for those scenarios. Suggested-by:
Aaron Ma <aaron.ma@canonical.com> Suggested-by:
Sasha Netfin <sasha.neftin@intel.com> Suggested-by:
-
Mario Limonciello authored
If the shutdown failed, the part will be thawed and running S0ix flows will put it into an undefined state. Reported-by:
-
Lijun Pan authored
Commit f9c6cea0 ("ibmvnic: Skip fatal error reset after passive init") says "If the passive CRQ initialization occurs before the FATAL reset task is processed, the FATAL error reset task would try to access a CRQ message queue that was freed, causing an oops. The problem may be most likely to occur during DLPAR add vNIC with a non-default MTU, because the DLPAR process will automatically issue a change MTU request. Fix this by not processing fatal error reset if CRQ is passively initialized after client-driven CRQ initialization fails." The original commit skips a specific reset condition, but that does not fix the problem it claims to fix, and misses a reset condition. The effective fix is commit 0e435bef ("ibmvnic: fix NULL pointer dereference in ibmvic_reset_crq") and commit a0faaa27 ("ibmvnic: fix NULL pointer dereference in reset_sub_crq_queues"). With above two fixes, there are no more crashes seen as described even without the original commit, so I would like to revert the original commit. Fixes: f9c6cea0 ("ibmvnic: Skip fatal error reset after passive init") Signed-off-by:
Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20201223204904.12677-1-ljp@linux.ibm.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Dinghao Liu authored
When mdiobus_register() fails, priv->mdio allocated by mdiobus_alloc() has not been freed, which leads to memleak. Fixes: e7f4dc35 ("mdio: Move allocation of interrupts into core") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201223110615.31389-1-dinghao.liu@zju.edu.cnSigned-off-by:
-
John Wang authored
When aggregating ncsi interfaces and dedicated interfaces to bond interfaces, the ncsi response handler will use the wrong net device to find ncsi_dev, so that the ncsi interface will not work properly. Here, we use the original net device to fix it. Fixes: 138635cc ("net/ncsi: NCSI response packet handler") Signed-off-by:
John Wang <wangzhiqiang.bj@bytedance.com> Link: https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang.bj@bytedance.comSigned-off-by:
-
Petr Machata authored
DCB uses the same handler function for both RTM_GETDCB and RTM_SETDCB messages. dcb_doit() bounces RTM_SETDCB mesasges if the user does not have the CAP_NET_ADMIN capability. However, the operation to be performed is not decided from the DCB message type, but from the DCB command. Thus DCB_CMD_*_GET commands are used for reading DCB objects, the corresponding SET and DEL commands are used for manipulation. The assumption is that set-like commands will be sent via an RTM_SETDCB message, and get-like ones via RTM_GETDCB. However, this assumption is not enforced. It is therefore possible to manipulate DCB objects without CAP_NET_ADMIN capability by sending the corresponding command in an RTM_GETDCB message. That is a bug. Fix it by validating the type of the request message against the type used for the response. Fixes: 2f90b865 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver") Signed-off-by:
Petr Machata <me@pmachata.org> Link: https://lore.kernel.org/r/a2a9b88418f3a58ef211b718f2970128ef9e3793.1608673640.git.me@pmachata.orgSigned-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: GSI interrupt handling fixes This series implements fixes for some issues related to handling interrupts when GSI channel and event ring commands complete. The first issue is that the completion condition for an event ring or channel command could occur while the associated interrupt is disabled. This would cause the interrupt to fire when it is subsequently enabled, even if the condition it signals had already been handled. The fix is to clear any pending interrupt conditions before re-enabling the interrupt. The second and third patches change how the success of an event ring or channel command is determined. These commands change the state of an event ring or channel. Previously the receipt of a completion interrupt was required to consider a command successful. Instead, a command is successful if it changes the state of the target event ring or channel in the way expected. This way the command can succeed even if the completion interrupt did not arrive while it was enabled. ==================== Link: https://lore.kernel.org/r/20201222180012.22489-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
This patch implements the same basic fix for event rings as the previous one does for channels. The result of issuing an event ring control command should be that the event ring changes state. If enabled, a completion interrupt signals that the event ring state has changed. This interrupt is enabled by gsi_evt_ring_command() and disabled again after the command has completed (or we time out). There is a window of time during which the command could complete successfully without interrupting. This would cause the event ring to transition to the desired new state. So whether a event ring command ends via completion interrupt or timeout, we can consider the command successful if the event ring has entered the desired state (and a failure if it has not, regardless of the cause). Fixes: b4175f87 ("net: ipa: only enable GSI event control IRQs when needed") Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The result of issuing a channel control command should be that the channel changes state. If enabled, a completion interrupt signals that the channel state has changed. This interrupt is enabled by gsi_channel_command() and disabled again after the command has completed (or we time out). There is a window of time--after the completion interrupt is disabled but before the channel state is read--during which the command could complete successfully without interrupting. This would cause the channel to transition to the desired new state. So whether a channel command ends via completion interrupt or timeout, we can consider the command successful if the channel has entered the desired state (and a failure if it has not, regardless of the cause). Fixes: d6c9e3f5 ("net: ipa: only enable generic command completion IRQ when needed"); Signed-off-by:
-
Alex Elder authored
We enable the completion interrupt for channel or event ring commands only when we issue them. The interrupt is disabled after the interrupt has fired, or after we have timed out waiting for it. If we time out, the command could complete after the interrupt has been disabled, causing a state change in the channel or event ring. The interrupt associated with that state change would be delivered the next time the completion interrupt is enabled. To avoid previous command completions interfering with new commands, clear all pending completion interrupts before re-enabling them for a new command. Fixes: b4175f87 ("net: ipa: only enable GSI event control IRQs when needed") Signed-off-by:
-
Noor Azura Ahmad Tarmizi authored
Add TGL-H PCI info and PCI IDs for the new TSN Controller to the list of supported devices. Signed-off-by:
Noor Azura Ahmad Tarmizi <noor.azura.ahmad.tarmizi@intel.com> Signed-off-by:
Voon Weifeng <weifeng.voon@intel.com> Signed-off-by:
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Link: https://lore.kernel.org/r/20201222160337.30870-1-muhammad.husaini.zulkifli@intel.comSigned-off-by:
-
Alex Elder authored
When the core clock rate and interconnect bandwidth specifications were moved into configuration data, a copy/paste bug was introduced, causing the memory interconnect bandwidth to be set three times rather than enabling the three different interconnects. Fix this bug. Fixes: 91d02f95 ("net: ipa: use config data for clocking") Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Link: https://lore.kernel.org/r/20201222151613.5730-1-elder@linaro.orgSigned-off-by:
-
Jeff Dike authored
virtnet_set_channels can recursively call cpus_read_lock if CONFIG_XPS and CONFIG_HOTPLUG are enabled. The path is: virtnet_set_channels - calls get_online_cpus(), which is a trivial wrapper around cpus_read_lock() netif_set_real_num_tx_queues netif_reset_xps_queues_gt netif_reset_xps_queues - calls cpus_read_lock() This call chain and potential deadlock happens when the number of TX queues is reduced. This commit the removes netif_set_real_num_[tr]x_queues calls from inside the get/put_online_cpus section, as they don't require that it be held. Fixes: 47be2479 ("virtio-net: fix the set affinity bug when CPU IDs are not consecutive") Signed-off-by:Jeff Dike <jdike@akamai.com> Acked-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20201223025421.671-1-jdike@akamai.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-drivers-2020-12-22' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.11 First set of fixes for v5.11, more fixes than usual this time. For ath11k we have several fixes for QCA6390 PCI support and mt76 has several. Also one build fix for mt76. mt76 * fix two NULL pointer dereference * fix build error when CONFIG_MAC80211_MESH is disabled rtlwifi * fix use-after-free in firmware handling code ath11k * error handling fixes * fix crash found during connect and disconnect test * handle HT disable better * avoid printing qmi memory failure during firmware bootup * disable ASPM during firmware bootup * tag 'wireless-drivers-2020-12-22' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers: MAINTAINERS: switch to different email address mt76: mt7915: fix MESH ifdef block mt76: mt76s: fix NULL pointer dereference in mt76s_process_tx_queue mt76: sdio: remove wake logic in mt76s_process_tx_queue mt76: usb: remove wake logic in mt76u_status_worker ath11k: pci: disable ASPM L0sLs before downloading firmware ath11k: qmi: try to allocate a big block of DMA memory first rtlwifi: rise completion at the last step of firmware callback mt76: mt76u: fix NULL pointer dereference in mt76u_status_worker ath11k: Fix ath11k_pci_fix_l1ss() ath11k: Fix error code in ath11k_core_suspend() ath11k: start vdev if a bss peer is already created ath11k: fix crash caused by NULL rx_channel ath11k: add missing null check on allocated skb ==================== Link: https://lore.kernel.org/r/20201222163727.D4336C433C6@smtp.codeaurora.orgSigned-off-by:
-
Manish Chopra authored
IPIP tunnels packets are unknown to device, hence these packets are incorrectly parsed and caused the packet corruption, so disable offlods for such packets at run time. Signed-off-by:
Manish Chopra <manishc@marvell.com> Signed-off-by:
Sudarsana Kalluru <skalluru@marvell.com> Signed-off-by:
Igor Russkikh <irusskikh@marvell.com> Link: https://lore.kernel.org/r/20201221145530.7771-1-manishc@marvell.comSigned-off-by:
-
Baruch Siach authored
Join adjacent questions to a single question line. This fixes the formatting of questions that were not part of the heading. Also, drop Q: and A: prefixes. We don't need them now that questions and answers are visually separated. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/f76078ba5547744f2ec178984c32fbc7dcd29a2b.1608454187.git.baruch@tkos.co.ilSigned-off-by:
-
Dinghao Liu authored
When mvneta_port_power_up() fails, we should execute cleanup functions after label err_netdev to avoid memleak. Fixes: 41c2b6b4 ("net: ethernet: mvneta: Add back interface mode validation") Signed-off-by:
-
Lijun Pan authored
Commit 34f0f4e3 ("ibmvnic: Fix login buffer memory leaks") frees login_rsp_buffer in release_resources() and send_login() because handle_login_rsp() does not free it. Commit f3ae59c0 ("ibmvnic: store RX and TX subCRQ handle array in ibmvnic_adapter struct") frees login_rsp_buffer in handle_login_rsp(). It seems unnecessary to free it in release_resources() and send_login(). There are chances that handle_login_rsp returns earlier without freeing buffers. Double-checking the buffer is harmless since release_login_buffer and release_login_rsp_buffer will do nothing if buffer is already freed. Fixes: f3ae59c0 ("ibmvnic: store RX and TX subCRQ handle array in ibmvnic_adapter struct") Fixes: 34f0f4e3 ("ibmvnic: Fix login buffer memory leaks") Signed-off-by:
-
Jakub Kicinski authored
When searching for inactive maintainers it's useful to filter out mailing list addresses. Such "maintainers" will obviously never feature in a "From:" line of an email or a review tag. Since "L:" entries only provide the address of a mailing list without a fancy name extend this pattern to "M:" entries. Alternatively we could reserve M: entries for humans only and move the fake "maintainers" to L:. While I'd personally prefer to reserve M: for humans only, I'm not 100% that's a great choice either, given most L: entries are in fact open mailing lists with public archives. Link: https://lore.kernel.org/r/20201219185538.750076-1-kuba@kernel.orgSigned-off-by:
-
Martin Blumenstingl authored
The dwmac glue registers on Amlogic Meson8b and newer SoCs has two clock inputs: - Meson8b and Meson8m2: MPLL2 and MPLL2 (the same parent is wired to both inputs) - GXBB, GXL, GXM, AXG, G12A, G12B, SM1: FCLK_DIV2 and MPLL2 All known vendor kernels and u-boots are using the first input only. We let the common clock framework automatically choose the "right" parent. For some boards this causes a problem though, specificially with G12A and newer SoCs. The clock input is used for generating the 125MHz RGMII TX clock. For the two input clocks this means on G12A: - FCLK_DIV2: 999999985Hz / 8 = 124999998.125Hz - MPLL2: 499999993Hz / 4 = 124999998.25Hz In theory MPLL2 is the "better" clock input because it's gets us 0.125Hz closer to the requested frequency than FCLK_DIV2. In reality however there is a resource conflict because MPLL2 is needed to generate some of the audio clocks. dwmac-meson8b probes first and sets up the clock tree with MPLL2. This works fine until the audio driver comes and "steals" the MPLL2 clocks and configures it with it's own rate (294909637Hz). The common clock framework happily changes the MPLL2 rate but does not reconfigure our RGMII TX clock tree, which then ends up at 73727409Hz, which is more than 40% off the requested 125MHz. Don't use the second clock input for now to force the common clock framework to always select the first parent. This mimics the behavior from the vendor driver and fixes the clock resource conflict with the audio driver on G12A boards. Once the common clock framework can handle this situation this change can be reverted again. Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Reported-by:
Thomas Graichen <thomas.graichen@gmail.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by:
-
- 22 Dec, 2020 8 commits
-
-
Stefan Chulski authored
During GoP port 2 Networking Complex Control mode of operation configurations, also GoP port 3 mode of operation was wrongly set. Patch removes these configurations. Fixes: f84bf386 ("net: mvpp2: initialize the GoP") Acked-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
Stefan Chulski <stefanc@marvell.com> Link: https://lore.kernel.org/r/1608462149-1702-1-git-send-email-stefanc@marvell.comSigned-off-by:
-
Guillaume Nault authored
PPPIOCGL2TPSTATS already uses 54. This shouldn't be a problem in practice, but let's keep the logical decreasing assignment scheme. Fixes: 4cf476ce ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Link: https://lore.kernel.org/r/e3a4c355e3820331d8e1fffef8522739aae58b57.1608380117.git.gnault@redhat.comSigned-off-by:
-
Dan Carpenter authored
This error path needs to disable the pci device before returning. Fixes: ede58ef2 ("atm: remove deprecated use of pci api") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/X93dmC4NX0vbTpGp@mwandaSigned-off-by:
-
Shannon Nelson authored
Let the FW know we have enough receive buffer space for the vlan tag if it isn't stripped. Fixes: 0f3154e6 ("ionic: Add Tx and Rx handling") Signed-off-by:
Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20201218215001.64696-1-snelson@pensando.ioSigned-off-by:
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== ucc_geth fixes This is three bug fixes that fell out of a series of cleanups of the ucc_geth driver. ==================== Link: https://lore.kernel.org/r/20201218105538.30563-1-rasmus.villemoes@prevas.dkSigned-off-by:
-
Rasmus Villemoes authored
ugeth is the netdiv_priv() part of the netdevice. Accessing the memory pointed to by ugeth (such as done by ucc_geth_memclean() and the two of_node_puts) after free_netdev() is thus use-after-free. Fixes: 80a9fad8 ("ucc_geth: fix module removal") Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by:
-
Rasmus Villemoes authored
Table 8-53 in the QUICC Engine Reference manual shows definitions of fields up to a size of 192 bytes, not just 128. But in table 8-111, one does find the text Base Address of the Global Transmitter Parameter RAM Page. [...] The user needs to allocate 128 bytes for this page. The address must be aligned to the page size. I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual; they both have this inconsistency (and the table numbers are the same). Adding a bit of debug printing, on my board the struct ucc_geth_tx_global_pram is allocated at offset 0x880, while the (opaque) ucc_geth_thread_data_tx gets allocated immediately afterwards, at 0x900. So whatever the engine writes into the thread data overlaps with the tail of the global tx pram (and devmem says that something does get written during a simple ping). I haven't observed any failure that could be attributed to this, but it seems to be the kind of thing that would be extremely hard to debug. So extend the struct definition so that we do allocate 192 bytes. Signed-off-by:
-
Rasmus Villemoes authored
All the buffers and registers are already set up appropriately for an MTU slightly above 1500, so we just need to expose this to the networking stack. AFAICT, there's no need to implement .ndo_change_mtu when the receive buffers are always set up to support the max_mtu. This fixes several warnings during boot on our mpc8309-board with an embedded mv88e6250 switch: mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0 ... mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4 ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead The last line explains what the DSA stack tries to do: achieving an MTU of 1500 on-the-wire requires that the master netdevice connected to the CPU port supports an MTU of 1500+the tagging overhead. Fixes: bfcb8132 ("net: dsa: configure the MTU for switch ports") Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
- 21 Dec, 2020 2 commits
-
-
Florian Fainelli authored
The driver is already allocating receive buffers of 2KiB and the Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE. Fixes: bfcb8132 ("net: dsa: configure the MTU for switch ports") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201218173843.141046-1-f.fainelli@gmail.comSigned-off-by:
-
Arend van Spriel authored
Switching to private mail account as work email is polluted with a legal disclaimer. Just making it extra clear by changing the email address in the MAINTAINERS file as well. Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Arend van Spriel <aspriel@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201220141807.17278-1-aspriel@gmail.com
-
- 20 Dec, 2020 5 commits
-
-
Randy Dunlap authored
Fix a build error when CONFIG_MAC80211_MESH is not enabled: ../drivers/net/wireless/mediatek/mt76/mt7915/init.c:47:2: error: expected expression before '}' token }, { ^ Fixes: af901eb4 ("mt76: mt7915: get rid of dbdc debugfs knob") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Cc: Shayne Chen <shayne.chen@mediatek.com> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Lorenzo Bianconi <lorenzo@kernel.org> Cc: Felix Fietkau <nbd@nbd.name> Cc: linux-wireless@vger.kernel.org Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Lorenzo Bianconi authored
Fix a possible NULL pointer dereference in mt76s_process_tx_queue that can occur if status thread runs before allocating tx queues Fixes: 6a618acb ("mt76: sdio: convert {status/net}_work to mt76_worker") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Similar to mmio/usb code path, remove wake logic in mt76s_process_tx_queue routine. Starting from commit 90d494c9 ("mt76: improve tx queue stop/wake"), the wake queue logic on the sdio status path is no longer necessary since the hw queues are no longer stopped on the mt76 tx path. Signed-off-by:
-
Lorenzo Bianconi authored
Similar to mmio code path, remove wake logic in mt76u_status_worker handler. Starting from commit 90d494c9 ("mt76: improve tx queue stop/wake")', the wake queue logic on the usb status path is no longer necessary since the hw queues are no longer stopped on the mt76 tx path. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git fixes for 5.11. Major changes: ath11k * add null check for skb allocation * fix crash found during connect/disconnect stress testing * fix for HT disabled case * brown paperbag fixes for my bugs in suspend code * fix an unnecessary qmi allocation during firmware bootup * disable ASPM during firmware bootup to avoid issues
-
- 19 Dec, 2020 4 commits
-
-
Stefan Chulski authored
Current PPPoE+IPv6 entry is jumping to 'next-hdr' field and not to 'DIP' field as done for IPv4. Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit") Reported-by:
Liron Himi <lironh@marvell.com> Signed-off-by:
-
Stefan Chulski authored
Issue: Flow control frame used to pause GoP(MAC) was delivered to the CPU and created a load on the CPU. Since XOFF/XON frames are used only by MAC, these frames should be dropped inside MAC. Fix: According to 802.3-2012 - IEEE Standard for Ethernet pause frame has unique destination MAC address 01-80-C2-00-00-01. Add TCAM parser entry to track and drop pause frames by destination MAC. Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by:
-
Stefan Chulski authored
Force link UP can be enabled by bootloader during tftpboot and breaks NFS support. Force link UP disabled during port init procedure. Fixes: f84bf386 ("net: mvpp2: initialize the GoP") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Incorrect loop in error path of nft_set_elem_expr_clone(), from Colin Ian King. 2) Missing xt_table_get_private_protected() to access table private data in x_tables, from Subash Abhinov Kasiviswanathan. 3) Possible oops in ipset hash type resize, from Vasily Averin. 4) Fix shift-out-of-bounds in ipset hash type, also from Vasily. * git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf: netfilter: ipset: fix shift-out-of-bounds in htable_bits() netfilter: ipset: fixes possible oops in mtype_resize netfilter: x_tables: Update remaining dereference to RCU netfilter: nftables: fix incorrect increment of loop counter ==================== Link: https://lore.kernel.org/r/20201218120409.3659-1-pablo@netfilter.orgSigned-off-by:
-
