- 24 Nov, 2020 40 commits
-
-
Wu Bo authored
[ Upstream commit cd0d83ea ] m_can_handle_state_change() is called with the new_state as an argument. In the switch statements for CAN_STATE_ERROR_ACTIVE, the comment and the following code indicate that a CAN_STATE_ERROR_WARNING is handled. This patch fixes this problem by changing the case to CAN_STATE_ERROR_WARNING. Signed-off-by:
Wu Bo <wubo.oduw@gmail.com> Link: http://lore.kernel.org/r/20200129022330.21248-2-wubo.oduw@gmail.com Cc: Dan Murphy <dmurphy@ti.com> Fixes: e0d1f481 ("can: m_can: add Bosch M_CAN controller support") Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Colin Ian King authored
[ Upstream commit 8a68cc0d ] The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit variable. In the case where time_ref->adapter->ts_used_bits is 32 or more this can lead to an oveflow. Avoid this by shifting using the BIT_ULL macro instead. Fixes: bb478555 ("can: usb: PEAK-System Technik USB adapters driver core") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201105112427.40688-1-colin.king@canonical.com Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit 81c9c8e0 ] The driver has to first fill the skb with data and then handle it to can_put_echo_skb(). This patch moves the can_put_echo_skb() down, right before sending the skb out via USB. Fixes: 51f3baad ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Cc: Remigiusz Kołłątaj <remigiusz.kollataj@mobica.com> Link: https://lore.kernel.org/r/20201111221204.1639007-1-mkl@pengutronix.de Signed-off-by:
-
Zhang Qilong authored
[ Upstream commit 7968c7c7 ] In the error handling, we should goto the probe_exit_candev to free ndev to prevent memory leak. Fixes: dabf54dd ("can: ti_hecc: Convert TI HECC driver to DT only driver") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201114111708.3465543-1-zhangqilong3@huawei.com Signed-off-by:
-
Alejandro Concepcion Rodriguez authored
[ Upstream commit a1e65407 ] netif_rx() is meant to be called from interrupt contexts. can_restart() may be called by can_restart_work(), which is called from a worqueue, so it may run in process context. Use netif_rx_ni() instead. Fixes: 39549eef ("can: CAN Network device driver and Netlink interface") Co-developed-by:
Loris Fauster <loris.fauster@ttcontrol.com> Signed-off-by:
Alejandro Concepcion Rodriguez <alejandro@acoro.eu> Link: https://lore.kernel.org/r/4e84162b-fb31-3a73-fa9a-9438b4bd5234@acoro.eu [mkl: use netif_rx_ni() instead of netif_rx_any_context()] Signed-off-by:
-
Anant Thazhemadam authored
[ Upstream commit 9aa9379d ] In canfd_rcv(), cfd->len is uninitialized when skb->len = 0, and this uninitialized cfd->len is accessed nonetheless by pr_warn_once(). Fix this uninitialized variable access by checking cfd->len's validity condition (cfd->len > CANFD_MAX_DLEN) separately after the skb->len's condition is checked, and appropriately modify the log messages that are generated as well. In case either of the required conditions fail, the skb is freed and NET_RX_DROP is returned, same as before. Fixes: d4689846 ("can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once") Reported-by: syzbot+9bcb0c9409066696d3aa@syzkaller.appspotmail.com Tested-by:
Anant Thazhemadam <anant.thazhemadam@gmail.com> Signed-off-by:
-
Anant Thazhemadam authored
[ Upstream commit c8c958a5 ] In can_rcv(), cfd->len is uninitialized when skb->len = 0, and this uninitialized cfd->len is accessed nonetheless by pr_warn_once(). Fix this uninitialized variable access by checking cfd->len's validity condition (cfd->len > CAN_MAX_DLEN) separately after the skb->len's condition is checked, and appropriately modify the log messages that are generated as well. In case either of the required conditions fail, the skb is freed and NET_RX_DROP is returned, same as before. Fixes: 8cb68751 ("can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once") Reported-by: syzbot+9bcb0c9409066696d3aa@syzkaller.appspotmail.com Tested-by:
-
Yi-Hung Wei authored
[ Upstream commit 9c2e14b4 ] Currently, we may set the tunnel option flag when the size of metadata is zero. For example, we set TUNNEL_GENEVE_OPT in the receive function no matter the geneve option is present or not. As this may result in issues on the tunnel flags consumers, this patch fixes the issue. Related discussion: * https://lore.kernel.org/netdev/1604448694-19351-1-git-send-email-yihung.wei@gmail.com/T/#u Fixes: 256c87c1 ("net: check tunnel option type in tunnel flags") Signed-off-by:
Yi-Hung Wei <yihung.wei@gmail.com> Link: https://lore.kernel.org/r/1605053800-74072-1-git-send-email-yihung.wei@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Leo Yan authored
[ Upstream commit b0e5a05c ] When execute command "perf lock report", it hits failure and outputs log as follows: perf: builtin-lock.c:623: report_lock_release_event: Assertion `!(seq->read_count < 0)' failed. Aborted This is an imbalance issue. The locking sequence structure "lock_seq_stat" contains the reader counter and it is used to check if the locking sequence is balance or not between acquiring and releasing. If the tool wrongly frees "lock_seq_stat" when "read_count" isn't zero, the "read_count" will be reset to zero when allocate a new structure at the next time; thus it causes the wrong counting for reader and finally results in imbalance issue. To fix this issue, if detects "read_count" is not zero (means still have read user in the locking sequence), goto the "end" tag to skip freeing structure "lock_seq_stat". Fixes: e4cef1f6 ("perf lock: Fix state machine to recognize lock sequence") Signed-off-by:
Leo Yan <leo.yan@linaro.org> Acked-by:
Jiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/r/20201104094229.17509-2-leo.yan@linaro.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Necip Fazil Yildiran authored
[ Upstream commit 676650d0 ] When TOUCHSCREEN_ADC is enabled and IIO_BUFFER is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for IIO_BUFFER_CB Depends on [n]: IIO [=y] && IIO_BUFFER [=n] Selected by [y]: - TOUCHSCREEN_ADC [=y] && !UML && INPUT [=y] && INPUT_TOUCHSCREEN [=y] && IIO [=y] The reason is that TOUCHSCREEN_ADC selects IIO_BUFFER_CB without depending on or selecting IIO_BUFFER while IIO_BUFFER_CB depends on IIO_BUFFER. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: aa132ffb ("input: touchscreen: resistive-adc-touch: add generic resistive ADC touchscreen") Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Acked-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20201102221504.541279-1-fazilyildiran@gmail.com Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 33d0d843 ] The SPI chip selects are represented as: cs-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>, <&gpio4 13 GPIO_ACTIVE_LOW>; , which means that they are used in GPIO function instead of native SPI mode. Fix the IOMUX for the chip select 1 to use GPIO4_13 instead of the native CSPI_SSI function. Fixes: c605cbf5 ("ARM: dts: imx: add device tree support for Freescale imx50evk board") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Sergey Matyukevich authored
[ Upstream commit 7dd8f0ba ] Commit bcf3440c ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") fixed micrel phy driver adding proper support for phy modes. Adapt imx6q-udoo board phy settings : explicitly set required delay configuration using "rgmii-id". Fixes: cbd54fe0 ("ARM: dts: imx6dl-udoo: Add board support based off imx6q-udoo") Signed-off-by:
Sergey Matyukevich <geomatsi@gmail.com> Reviewed-by:
-
Nenad Peric authored
[ Upstream commit 107954af ] RX and TX delay are provided by ethernet PHY. Reflect that in ethernet node. Fixes: 44a94c7e ("arm64: dts: allwinner: H5: Restore EMAC changes") Signed-off-by:
Nenad Peric <nperic@gmail.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Jernej Skrabec <jernej.skrabec@siol.net> Link: https://lore.kernel.org/r/20201028115817.68113-1-nperic@gmail.com Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit 31b4d8e1 ] MIPS should export its local version of "has_transparent_hugepage" so that loadable modules (dax) can use it. Fixes this build error: ERROR: modpost: "has_transparent_hugepage" [drivers/dax/dax.ko] undefined! Fixes: fd8cfd30 ("arch: fix has_transparent_hugepage()") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: linux-mips@vger.kernel.org Cc: Dan Williams <dan.j.williams@intel.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: linux-nvdimm@lists.01.org Cc: Hugh Dickins <hughd@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 33b6c39e ] The "revid" is used to store negative error codes so it should be an int type. Fixes: e27c7292 ("Input: add driver for ADXL345/346 Digital Accelerometers") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20201026072824.GA1620546@mwanda Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 1a9a8910 ] The Ethernet PHY on the Bananapi M64 has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: e7295499 ("arm64: allwinner: bananapi-m64: Enable dwmac-sun8i") Fixes: 94f44288 ("arm64: dts: allwinner: A64: Restore EMAC changes") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by:
-
Chen-Yu Tsai authored
[ Upstream commit 57dbe558 ] The Ethernet PHY on the Bananapi M3 and Cubietruck Plus have the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 03935994 ("ARM: dts: sun8i: a83t: Enable Ethernet on two boards") Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit e080ab31 ] The Ethernet PHY on the Orange Pi Plus 2E has the RX and TX delays enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins. Fix the phy-mode description to correct reflect this so that the implementation doesn't reconfigure the delays incorrectly. This happened with commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx delay config"). Fixes: 4904337f ("ARM: dts: sunxi: Restore EMAC changes (boards)") Fixes: 7a78ef92 ("ARM: sun8i: h3: Enable EMAC with external PHY on Orange Pi Plus 2E") Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit 8d80e2f0 ] This reverts commit 75ee680c. Turns out the activity and link LEDs on the RJ45 port are active low, just like on the Orange Pi PC. Revert the commit that says otherwise. Fixes: 75ee680c ("arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high") Fixes: 4904337f ("ARM: dts: sunxi: Restore EMAC changes (boards)") Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit b3eec321 ] Ethernet PHY on BananaPi M2 Ultra provides RX and TX delays. Fix ethernet node to reflect that fact. Fixes: c36fd5a4 ("ARM: dts: sun8i: r40: bananapi-m2-ultra: Enable GMAC ethernet controller") Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit b34bf9f6 ] RX and TX delay are provided by ethernet PHY. Reflect that in ethernet node. Fixes: 44a94c7e ("arm64: dts: allwinner: H5: Restore EMAC changes") Signed-off-by:
-
Jernej Skrabec authored
[ Upstream commit 927f42fc ] According to board schematic, PHY provides both, RX and TX delays. However, according to "fix" Realtek provided for this board, only TX delay should be provided by PHY. Tests show that both variants work but TX only PHY delay works slightly better. Update ethernet node to reflect the fact that PHY provides TX delay. Fixes: 94f44288 ("arm64: dts: allwinner: A64: Restore EMAC changes") Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 22843291 ] __sb_start_write has some weird looking lockdep code that claims to exist to handle nested freeze locking requests from xfs. The code as written seems broken -- if we think we hold a read lock on any of the higher freeze levels (e.g. we hold SB_FREEZE_WRITE and are trying to lock SB_FREEZE_PAGEFAULT), it converts a blocking lock attempt into a trylock. However, it's not correct to downgrade a blocking lock attempt to a trylock unless the downgrading code or the callers are prepared to deal with that situation. Neither __sb_start_write nor its callers handle this at all. For example: sb_start_pagefault ignores the return value completely, with the result that if xfs_filemap_fault loses a race with a different thread trying to fsfreeze, it will proceed without pagefault freeze protection (thereby breaking locking rules) and then unlocks the pagefault freeze lock that it doesn't own on its way out (thereby corrupting the lock state), which leads to a system hang shortly afterwards. Normally, this won't happen because our ownership of a read lock on a higher freeze protection level blocks fsfreeze from grabbing a write lock on that higher level. *However*, if lockdep is offline, lock_is_held_type unconditionally returns 1, which means that percpu_rwsem_is_held returns 1, which means that __sb_start_write unconditionally converts blocking freeze lock attempts into trylocks, even when we *don't* hold anything that would block a fsfreeze. Apparently this all held together until 5.10-rc1, when bugs in lockdep caused lockdep to shut itself off early in an fstests run, and once fstests gets to the "race writes with freezer" tests, kaboom. This might explain the long trail of vanishingly infrequent livelocks in fstests after lockdep goes offline that I've never been able to diagnose. We could fix it by spinning on the trylock if wait==true, but AFAICT the locking works fine if lockdep is not built at all (and I didn't see any complaints running fstests overnight), so remove this snippet entirely. NOTE: Commit f4b554af in 2015 created the current weird logic (which used to exist in a different form in commit 5accdf82 from 2012) in __sb_start_write. XFS solved this whole problem in the late 2.6 era by creating a variant of transactions (XFS_TRANS_NO_WRITECOUNT) that don't grab intwrite freeze protection, thus making lockdep's solution unnecessary. The commit claims that Dave Chinner explained that the trylock hack + comment could be removed, but nobody ever did. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 891deb87 ] cpu_psci_cpu_die() is called in the context of the dying CPU, which will no longer be online or tracked by RCU. It is therefore not generally safe to call printk() if the PSCI "cpu off" request fails, so remove the pr_crit() invocation. Cc: Qian Cai <cai@redhat.com> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20201106103602.9849-2-will@kernel.org Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 7daaa063 ] The Medion Akoya E2228T's ACPI _LID implementation is quite broken, it has the same issues as the one from the Medion Akoya E2215T: 1. For notifications it uses an ActiveLow Edge GpioInt, rather then an ActiveBoth one, meaning that the device is only notified when the lid is closed, not when it is opened. 2. Matching with this its _LID method simply always returns 0 (closed) In order for the Linux LID code to work properly with this implementation, the lid_init_state selection needs to be set to ACPI_BUTTON_LID_INIT_OPEN, add a DMI quirk for this. While working on this I also found out that the MD60### part of the model number differs per country/batch while all of the E2215T and E2228T models have this issue, so also remove the " MD60198" part from the E2215T quirk. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Aaron Lewis authored
[ Upstream commit df11f7dd ] Fix the layout of 'struct desc64' to match the layout described in the SDM Vol 3, Chapter 3 "Protected-Mode Memory Management", section 3.4.5 "Segment Descriptors", Figure 3-8 "Segment Descriptor". The test added later in this series relies on this and crashes if this layout is not correct. Signed-off-by:
Aaron Lewis <aaronlewis@google.com> Reviewed-by:
Alexander Graf <graf@amazon.com> Message-Id: <20201012194716.3950330-2-aaronlewis@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Can Guo authored
[ Upstream commit da3fecb0 ] The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be decreased back in ufshcd_ungate_work() in a paired way. However, if specific ufshcd_hold/release sequences are met, it is possible that scsi_block_reqs_cnt is increased twice but only one ungate work is queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and ufshcd_ungate_work() in a paired way, increase it only if queue_work() returns true. Link: https://lore.kernel.org/r/1604384682-15837-2-git-send-email-cang@codeaurora.org Reviewed-by:
Hongwu Su <hongwus@codeaurora.org> Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jianqun Xu authored
[ Upstream commit 63fbf801 ] There need to enable pclk_gpio when do irq_create_mapping, since it will do access to gpio controller. Signed-off-by:
Jianqun Xu <jay.xu@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by: Kever Yang<kever.yang@rock-chips.com> Link: https://lore.kernel.org/r/20201013063731.3618-3-jay.xu@rock-chips.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Joel Stanley authored
[ Upstream commit 3d517945 ] When removing the driver we would hit BUG_ON(!list_empty(&dev->ptype_specific)) in net/core/dev.c due to still having the NC-SI packet handler registered. # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/unbind ------------[ cut here ]------------ kernel BUG at net/core/dev.c:10254! Internal error: Oops - BUG: 0 [#1] SMP ARM CPU: 0 PID: 115 Comm: sh Not tainted 5.10.0-rc3-next-20201111-00007-g02e0365710c4 #46 Hardware name: Generic DT based system PC is at netdev_run_todo+0x314/0x394 LR is at cpumask_next+0x20/0x24 pc : [<806f5830>] lr : [<80863cb0>] psr: 80000153 sp : 855bbd58 ip : 00000001 fp : 855bbdac r10: 80c03d00 r9 : 80c06228 r8 : 81158c54 r7 : 00000000 r6 : 80c05dec r5 : 80c05d18 r4 : 813b9280 r3 : 813b9054 r2 : 8122c470 r1 : 00000002 r0 : 00000002 Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 85514008 DAC: 00000051 Process sh (pid: 115, stack limit = 0x7cb5703d) ... Backtrace: [<806f551c>] (netdev_run_todo) from [<80707eec>] (rtnl_unlock+0x18/0x1c) r10:00000051 r9:854ed710 r8:81158c54 r7:80c76bb0 r6:81158c10 r5:8115b410 r4:813b9000 [<80707ed4>] (rtnl_unlock) from [<806f5db8>] (unregister_netdev+0x2c/0x30) [<806f5d8c>] (unregister_netdev) from [<805a8180>] (ftgmac100_remove+0x20/0xa8) r5:8115b410 r4:813b9000 [<805a8160>] (ftgmac100_remove) from [<805355e4>] (platform_drv_remove+0x34/0x4c) Fixes: bd466c3f ("net/faraday: Support NCSI mode") Signed-off-by:
Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201117024448.1170761-1-joel@jms.id.au Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joel Stanley authored
[ Upstream commit 1922a46b ] If a user unbinds and re-binds a NC-SI aware driver the kernel will attempt to register the netlink interface at runtime. The structure is marked __ro_after_init so registration fails spectacularly at this point. # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/unbind # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/bind ftgmac100 1e660000.ethernet: Read MAC address 52:54:00:12:34:56 from chip ftgmac100 1e660000.ethernet: Using NCSI interface 8<--- cut here --- Unable to handle kernel paging request at virtual address 80a8f858 pgd = 8c768dd6 [80a8f858] *pgd=80a0841e(bad) Internal error: Oops: 80d [#1] SMP ARM CPU: 0 PID: 116 Comm: sh Not tainted 5.10.0-rc3-next-20201111-00003-gdd25b227ec1e #51 Hardware name: Generic DT based system PC is at genl_register_family+0x1f8/0x6d4 LR is at 0xff26ffff pc : [<8073f930>] lr : [<ff26ffff>] psr: 20000153 sp : 8553bc80 ip : 81406244 fp : 8553bd04 r10: 8085d12c r9 : 80a8f73c r8 : 85739000 r7 : 00000017 r6 : 80a8f860 r5 : 80c8ab98 r4 : 80a8f858 r3 : 00000000 r2 : 00000000 r1 : 81406130 r0 : 00000017 Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 85524008 DAC: 00000051 Process sh (pid: 116, stack limit = 0x1f1988d6) ... Backtrace: [<8073f738>] (genl_register_family) from [<80860ac0>] (ncsi_init_netlink+0x20/0x48) r10:8085d12c r9:80c8fb0c r8:85739000 r7:00000000 r6:81218000 r5:85739000 r4:8121c000 [<80860aa0>] (ncsi_init_netlink) from [<8085d740>] (ncsi_register_dev+0x1b0/0x210) r5:8121c400 r4:8121c000 [<8085d590>] (ncsi_register_dev) from [<805a8060>] (ftgmac100_probe+0x6e0/0x778) r10:00000004 r9:80950228 r8:8115bc10 r7:8115ab00 r6:9eae2c24 r5:813b6f88 r4:85739000 [<805a7980>] (ftgmac100_probe) from [<805355ec>] (platform_drv_probe+0x58/0xa8) r9:80c76bb0 r8:00000000 r7:80cd4974 r6:80c76bb0 r5:8115bc10 r4:00000000 [<80535594>] (platform_drv_probe) from [<80532d58>] (really_probe+0x204/0x514) r7:80cd4974 r6:00000000 r5:80cd4868 r4:8115bc10 Jakub pointed out that ncsi_register_dev is obviously broken, because there is only one family so it would never work if there was more than one ncsi netdev. Fix the crash by registering the netlink family once on boot, and drop the code to unregister it. Fixes: 955dc68c ("net/ncsi: Add generic netlink family") Signed-off-by:
Samuel Mendoza-Jonas <sam@mendozajonas.com> Link: https://lore.kernel.org/r/20201112061210.914621-1-joel@jms.id.au Signed-off-by:
-
Filip Moc authored
[ Upstream commit df8d85d8 ] LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set. Signed-off-by:
Filip Moc <dev@moc6.cz> Acked-by:
Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20201117173631.GA550981@moc6.cz Signed-off-by:
-
Vladyslav Tarasiuk authored
[ Upstream commit 470b7475 ] Currently when QoS is enabled for VF and any min_rate is configured, the driver sets bw_share value to at least 1 and doesn’t allow to set it to 0 to make minimal rate unlimited. It means there is always a minimal rate configured for every VF, even if user tries to remove it. In order to make QoS disable possible, check whether all vports have configured min_rate = 0. If this is true, set their bw_share to 0 to disable min_rate limitations. Fixes: c9497c98 ("net/mlx5: Add support for setting VF min rate") Signed-off-by:
Vladyslav Tarasiuk <vladyslavt@nvidia.com> Reviewed-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Ryan Sharpelletti authored
[ Upstream commit 1b9e2a8c ] During loss recovery, retransmitted packets are forced to use TCP timestamps to calculate the RTT samples, which have a millisecond granularity. BBR is designed using a microsecond granularity. As a result, multiple RTT samples could be truncated to the same RTT value during loss recovery. This is problematic, as BBR will not enter PROBE_RTT if the RTT sample is <= the current min_rtt sample, meaning that if there are persistent losses, PROBE_RTT will constantly be pushed off and potentially never re-entered. This patch makes sure that BBR enters PROBE_RTT by checking if RTT sample is < the current min_rtt sample, rather than <=. The Netflix transport/TCP team discovered this bug in the Linux TCP BBR code during lab tests. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
Ryan Sharpelletti <sharpelletti@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Link: https://lore.kernel.org/r/20201116174412.1433277-1-sharpelletti.kdev@gmail.com Signed-off-by:
-
Xin Long authored
[ Upstream commit 057a10fa ] A call trace was found in Hangbin's Codenomicon testing with debug kernel: [ 2615.981988] ODEBUG: free active (active state 0) object type: timer_list hint: sctp_generate_proto_unreach_event+0x0/0x3a0 [sctp] [ 2615.995050] WARNING: CPU: 17 PID: 0 at lib/debugobjects.c:328 debug_print_object+0x199/0x2b0 [ 2616.095934] RIP: 0010:debug_print_object+0x199/0x2b0 [ 2616.191533] Call Trace: [ 2616.194265] <IRQ> [ 2616.202068] debug_check_no_obj_freed+0x25e/0x3f0 [ 2616.207336] slab_free_freelist_hook+0xeb/0x140 [ 2616.220971] kfree+0xd6/0x2c0 [ 2616.224293] rcu_do_batch+0x3bd/0xc70 [ 2616.243096] rcu_core+0x8b9/0xd00 [ 2616.256065] __do_softirq+0x23d/0xacd [ 2616.260166] irq_exit+0x236/0x2a0 [ 2616.263879] smp_apic_timer_interrupt+0x18d/0x620 [ 2616.269138] apic_timer_interrupt+0xf/0x20 [ 2616.273711] </IRQ> This is because it holds asoc when transport->proto_unreach_timer starts and puts asoc when the timer stops, and without holding transport the transport could be freed when the timer is still running. So fix it by holding/putting transport instead for proto_unreach_timer in transport, just like other timers in transport. v1->v2: - Also use sctp_transport_put() for the "out_unlock:" path in sctp_generate_proto_unreach_event(), as Marcelo noticed. Fixes: 50b5d6ad ("sctp: Fix a race between ICMP protocol unreachable and connect()") Reported-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Link: https://lore.kernel.org/r/102788809b554958b13b95d33440f5448113b8d6.1605331373.git.lucien.xin@gmail.com Signed-off-by:
-
Zhang Changzhong authored
[ Upstream commit 3beb9be1 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 3ced0a88 ("qlcnic: Add support to run firmware POST") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1605248186-16013-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by:
-
Zhang Changzhong authored
[ Upstream commit cb47d16e ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 469981b1 ("qed: Add unaligned and packed packet processing") Fixes: fcb39f6c ("qed: Add mpa buffer descriptors for storing and processing mpa fpdus") Fixes: 1e28eaad ("qed: Add iWARP support for fpdu spanned over more than two tcp packets") Reported-by:
-
Dongli Zhang authored
[ Upstream commit d8c19014 ] The ethernet driver may allocate skb (and skb->data) via napi_alloc_skb(). This ends up to page_frag_alloc() to allocate skb->data from page_frag_cache->va. During the memory pressure, page_frag_cache->va may be allocated as pfmemalloc page. As a result, the skb->pfmemalloc is always true as skb->data is from page_frag_cache->va. The skb will be dropped if the sock (receiver) does not have SOCK_MEMALLOC. This is expected behaviour under memory pressure. However, once kernel is not under memory pressure any longer (suppose large amount of memory pages are just reclaimed), the page_frag_alloc() may still re-use the prior pfmemalloc page_frag_cache->va to allocate skb->data. As a result, the skb->pfmemalloc is always true unless page_frag_cache->va is re-allocated, even if the kernel is not under memory pressure any longer. Here is how kernel runs into issue. 1. The kernel is under memory pressure and allocation of PAGE_FRAG_CACHE_MAX_ORDER in __page_frag_cache_refill() will fail. Instead, the pfmemalloc page is allocated for page_frag_cache->va. 2: All skb->data from page_frag_cache->va (pfmemalloc) will have skb->pfmemalloc=true. The skb will always be dropped by sock without SOCK_MEMALLOC. This is an expected behaviour. 3. Suppose a large amount of pages are reclaimed and kernel is not under memory pressure any longer. We expect skb->pfmemalloc drop will not happen. 4. Unfortunately, page_frag_alloc() does not proactively re-allocate page_frag_alloc->va and will always re-use the prior pfmemalloc page. The skb->pfmemalloc is always true even kernel is not under memory pressure any longer. Fix this by freeing and re-allocating the page instead of recycling it. References: https://lore.kernel.org/lkml/20201103193239.1807-1-dongli.zhang@oracle.com/ References: https://lore.kernel.org/linux-mm/20201105042140.5253-1-willy@infradead.org/ Suggested-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Aruna Ramakrishna <aruna.ramakrishna@oracle.com> Cc: Bert Barbe <bert.barbe@oracle.com> Cc: Rama Nichanamatlu <rama.nichanamatlu@oracle.com> Cc: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com> Cc: Manjunath Patil <manjunath.b.patil@oracle.com> Cc: Joe Jin <joe.jin@oracle.com> Cc: SRINIVAS <srinivas.eeda@oracle.com> Fixes: 79930f58 ("net: do not deplete pfmemalloc reserve") Signed-off-by:
Dongli Zhang <dongli.zhang@oracle.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20201115201029.11903-1-dongli.zhang@oracle.com Signed-off-by:
-
Xie He authored
[ Upstream commit 4ee18c17 ] The x25_disconnect function in x25_subr.c would decrease the refcount of "x25->neighbour" (struct x25_neigh) and reset this pointer to NULL. However, the x25_rx_call_request function in af_x25.c, which is called when we receive a connection request, does not increase the refcount when it assigns the pointer. Fix this issue by increasing the refcount of "struct x25_neigh" in x25_rx_call_request. This patch fixes frequent kernel crashes when using AF_X25 sockets. Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201112103506.5875-1-xie.he.0141@gmail.com Signed-off-by:
-
Subash Abhinov Kasiviswanathan authored
[ Upstream commit fc70f5bf ] During rmnet unregistration, the real device rx_handler is first cleared followed by the removal of rx_handler_data after the rcu synchronization. Any packets in the receive path may observe that the rx_handler is NULL. However, there is no check when dereferencing this value to use the rmnet_port information. This fixes following splat by adding the NULL check. Unable to handle kernel NULL pointer dereference at virtual address 000000000000000d pc : rmnet_rx_handler+0x124/0x284 lr : rmnet_rx_handler+0x124/0x284 rmnet_rx_handler+0x124/0x284 __netif_receive_skb_core+0x758/0xd74 __netif_receive_skb+0x50/0x17c process_backlog+0x15c/0x1b8 napi_poll+0x88/0x284 net_rx_action+0xbc/0x23c __do_softirq+0x20c/0x48c Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Signed-off-by:
Sean Tranchetti <stranche@codeaurora.org> Signed-off-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Link: https://lore.kernel.org/r/1605298325-3705-1-git-send-email-subashab@codeaurora.org Signed-off-by:
-
Aya Levin authored
[ Upstream commit 6d9c8d15 ] Slave function read the following capabilities from the wrong offset: 1. log_mc_entry_sz 2. fs_log_entry_sz 3. log_mc_hash_sz Fix that by adjusting these capabilities offset to match firmware layout. Due to the wrong offset read, the following issues might occur: 1+2. Negative value reported at max_mcast_qp_attach. 3. Driver to init FW with multicast hash size of zero. Fixes: a40ded60 ("net/mlx4_core: Add masking for a few queries on HCA caps") Signed-off-by:
Aya Levin <ayal@nvidia.com> Reviewed-by:
Eran Ben Elisha <eranbe@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201118081922.553-1-tariqt@nvidia.com Signed-off-by:
-
