summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-12-15wifi: mwifiex: configure BSSID consistently when starting APDavid Lin
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly. Upstream-Status: Submitted [https://lore.kernel.org/all/20231215005118.17031-1-yu-hao.lin@nxp.com/] Signed-off-by: David Lin <yu-hao.lin@nxp.com> Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Tested-by: Rafael Beims <rafael.beims@toradex.com> # Verdin iMX8MP/SD8997 SD Acked-by: Brian Norris <briannorris@chromium.org>
2023-11-14mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for Micron eMMC Q2J54ABean Huo
Micron MTFC4GACAJCN eMMC supports cache but requires that flush cache operation be allowed only after a write has occurred. Otherwise, the cache flush command or subsequent commands will time out. Upstream-Status: Backport [ed9009ad300c0f15a3ecfe9613547b1962bde02c] Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Rafael Beims <rafael.beims@toradex.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231030224809.59245-1-beanhuo@iokpp.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-09-27gpu: drm: imx: lcdif-mux: enable the clk_pixel when the driver bindsStefan Eichenberger
Make sure to enable the clk_pixel clock during bind so that all other driver in the display pipeline can rely on it. Without this change we might see ghosting effects in around 10% of the reboots because something in the display pipeline runs out of sync. With this change we don't disable the clk_pixel when the display is turned off so this might increase the power consumption in standby mode a bit. However, it would require some bigger changes in the display pipeline to allow this. Upstream-Status: Inappropriate [other] The dpu is currently only supported in the downstream kernel. A fix will most likely be applied by NXP to the downstream kernel. A similar patch was provided by them but it breaks the DPMS off/standby mode. See this ticket for more information: https://support.nxp.com/s/case/5002p00002vUMOL/ghosting-effect-on-parallel-rgb-interface Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
2022-06-28mxc_lcdif.c: add additonal LCD timingsMax Krummenacher
[ commit 20ab378e5462c4e9b4703264d143d3aeb9882023 on toradex_4.14-2.3.x-imx ] FusionF10A: 1024x600, used with external parallel to LVDS converter FusionF07A: 800x480 EDT-VGA: 640x480 EDT-480x272: 480x272 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> [ps: forward port from toradex_4.14-2.3.x-imx] Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2022-05-24mwifiex: Add SD8997 SDIO-UART firmwareAndrejs Cainikovs
commit 562354ab9f0aa4fcd8f2184506dcb9c18a792182 upstream. With a recent change now it is possible to detect the strapping option on SD8997, which allows to pick up a correct firmware for either SDIO-SDIO or SDIO-UART. This commit enables SDIO-UART firmware on SD8997. Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220422090313.125857-3-andrejs.cainikovs@toradex.com
2022-05-24mwifiex: Select firmware based on strappingAndrejs Cainikovs
commit 255ca28a659d3cfb069f73c7644853ed93aecdb0 upstream. Some WiFi/Bluetooth modules might have different host connection options, allowing to either use SDIO for both WiFi and Bluetooth, or SDIO for WiFi and UART for Bluetooth. It is possible to detect whether a module has SDIO-SDIO or SDIO-UART connection by reading its host strap register. This change introduces a way to automatically select appropriate firmware depending of the connection method, and removes a need of symlinking or overwriting the original firmware file with a required one. Host strap register used in this commit comes from the NXP driver [1] hosted at Code Aurora. [1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlinux/moal_sdio_mmc.c?h=rel_imx_5.4.70_2.3.2&id=688b67b2c7220b01521ffe560da7eee33042c7bd#n1274 Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220422090313.125857-2-andrejs.cainikovs@toradex.com
2022-05-20Revert "clk: imx7d: Remove audio_mclk_root_clk"Philippe Schenker
This reverts commit b576488fa3b5715a1ef3eafc0b1c1d3514345613. As it uses to break audio on i.MX 7 based modules. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2022-05-19Merge remote-tracking branch 'gh-fslc/5.4-2.3.x-imx' into toradex_5.4-2.3.x-imxPhilippe Schenker
2022-05-19Merge tag 'v5.4.193' into update-to-2.3.7__5.4-2.3.x-imxPhilippe Schenker
This is the 5.4.193 stable release Conflicts: arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts drivers/edac/synopsys_edac.c drivers/mmc/host/sdhci-esdhc-imx.c drivers/mmc/host/sdhci.c drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c sound/soc/codecs/msm8916-wcd-analog.c
2022-05-19LF-3705-1: caam: imx8m: fix the built-in caam driver cannot match soc_idAlice Guo
drivers/soc/imx/soc-imx8m.c is probed later than the caam driver so that return -EPROBE_DEFER is needed after calling soc_device_match() in drivers/crypto/caam/ctrl.c. For i.MX8M, soc_device_match returning NULL can be considered that the SoC device has not been probed yet, so it returns -EPROBE_DEFER directly. Fixes: 6375d33dce9a ("soc: imx8m: change to use platform driver") Signed-off-by: Alice Guo <alice.guo@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> (cherry picked from commit d5df21ff810453741e23aa62de3e3911957c42b1)
2022-05-18LF-4020: clk: imx8qxp: Fix elcdif_pll clockRobert Chiras
Move the elcdif_pll clock initialization before the lcd_clk, since the elcdif_clk needs to be initialized ahead of lcd_clk, being its parent. This change fixes issues with the LCD clocks during suspend/resume. Signed-off-by: Robert Chiras <robert.chiras@nxp.com> Suggested-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> Acked-by: Laurentiu Palcu <laurentiu.palcu@nxp.com> (cherry picked from commit 0668a88908ccc841081b0509d80e0b4f6b5f9a78)
2022-05-18MLK-25088: drm/mxsfb: Change connector type for panelOliver Brown
The connector type for a panel without a bridge should be DRM_MODE_CONNECTOR_DPI. Signed-off-by: Oliver Brown <oliver.brown@nxp.com> Reviewed-by: Robert Chiras <robert.chiras@nxp.com> (cherry picked from commit cc8cfef78c0ebaa5936af8d1a65f9372680b6634)
2022-05-18LF-3217: media: isi: cap: call streamoff if the process abnormal exitGuoniu.zhou
For normal case, userspace should call streamon/streamoff balance, but for some special case, the process will be killed or terminated and the streamoff ioctl will be ignored. So driver need to handle the case. Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com> Reviewed-by: Robby Cai <robby.cai@nxp.com> (cherry picked from commit 057b44588095cb6be35175f42467c1481d0dd54b)
2022-05-18MLK-25649-7 rpmsg: imx: Add support for identifying SCU wakeup source from sysfsRanjani Vaidyanathan
Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit d7b1dd90185df67fe1e713ff439fc898201cb8c8) (cherry picked from commit 5693275abe2a558f7a433bba23eb8ae35bd30749)
2022-05-18MLK-25649-8 rtc: imx-sc: Add support for identifying SCU wakeup source from ↵Ranjani Vaidyanathan
sysfs Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit ae44e6f054423fd6b228a147571cc77bc768138e) (cherry picked from commit 8924966cd6cb48c0c549d07f028ee544fa6dca1a)
2022-05-18MLK-25649-9 watchdog: imx_sc_wdt: Add support for identifying SCU wakeup ↵Ranjani Vaidyanathan
source from sysfs Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit 9d2e7cc3a10f2ce1e36fc40acb494494bed08109) (cherry picked from commit 0096d3876d96b1b400f5bf2cb999078236e28bf0) Ported from codeaurora/imx_5.4.70_2.3.0 Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2022-05-18MLK-25649-4 mailbox: imx: Add support for identifying SCU wakeup source from ↵Ranjani Vaidyanathan
sysfs Record SCU wakeup interrupt in /sys/power/pm_wakeup_irq Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit e8d90d8901e42f9ac039086af9f1829030204fa8) (cherry picked from commit 2b5bb07b7c25ae047530a78d5d19466f7b6b330c)
2022-05-18MLK-25649-6 remoteproc: imx_proc: Add support for identifying SCU wakeup sou ↵Ranjani Vaidyanathan
rce from sysfs Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit 012932b938d28eb47d05a505705fad3735b53d5d)
2022-05-18MLK-25649-10 firmware: seco_mu: Add support for identifying SCU wakeup ↵Ranjani Vaidyanathan
source from sysfs Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit 215433a807576abc8cafbbb1b64715650ed98224) (cherry picked from commit 7ca430575e9ae034a2c28798fa8dd7b931f0733c)
2022-05-18MLK-25649-2 gpio: mxc: Add support for identifying SCU wakeup source from sysfsRanjani Vaidyanathan
Consolidate SCU wakeup defines in the header file. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit 7d1a364e453397d3659cb80832e2297d49b62706) (cherry picked from commit 36bde0d134c97cfbbac9ad1078a2fbeb9b2cd9fa)
2022-05-18MLK-25649-1 firmware: imx: imx-scu-irq: Add support for identifying SCU ↵Ranjani Vaidyanathan
wakeup source from sysfs Record SCU wakeup interrupt in /sys/power/pm_wakeup_irq The user can further identify the exact wakeup source by using the following interface: cat /sys/firmware/scu_wakeup_source/wakeup_src The above will print the wake groups and the irqs that could have contributed to waking up the kernel. For example if ON/OFF button was the wakeup source: cat /sys/firmware/scu_wakeup_source/wakeup_src Wakeup source group = 3, irq = 0x1 The user can refer to the SCFW API documentation to identify all the wake groups and irqs. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com> (cherry picked from commit d49daabfb43eddf94144560fc2eef58015311454) (cherry picked from commit fed9f95ad512fd4b4cca7c8bfd08a78ddcaebeb9)
2022-05-18LF-4265: mailbox: imx: fix wakeup failure from freeze modeRobin Gong
Since IRQF_NO_SUSPEND used for imx mailbox driver, that means this irq can't be used for wakeup source so that can't wakeup from freeze mode. Add pm_system_wakeup() to wakeup from freeze mode. Signed-off-by: Robin Gong <yibin.gong@nxp.com> Reviewed-by: Jacky Bai <ping.bai@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> (cherry picked from commit d12a9c6240167bab5a49180cf642cc9e6e518bca) (cherry picked from commit 23857411888f489fbff023d05a38a0cdc035af26)
2022-05-18MLK-25731: drm: imx: hdp: correct ipg clk disableOliver Brown
Change enable calls to disable calls in imx8qm_ipg_clk_disable Signed-off-by: Oliver Brown <oliver.brown@nxp.com> (cherry picked from commit 8d4eef776974fce47db4447226b3834d4eb5afc5)
2022-05-18MLK-25498 gpu: drm: imx: Add missing PHY init to cdns_mhdp_imx_resumeOliver Brown
This fixes an issue where there is no display after resuming from suspend due to missing PHY initialization. Signed-off-by: Oliver Brown <oliver.brown@nxp.com> Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> (cherry picked from commit 23617be31285b84b68e652d3fb39dc73875126c1)
2022-05-13net: phy: Fix race condition on link status changeFrancesco Dolcini
commit 91a7cda1f4b8bdf770000a3b60640576dafe0cec upstream. This fixes the following error caused by a race condition between phydev->adjust_link() and a MDIO transaction in the phy interrupt handler. The issue was reproduced with the ethernet FEC driver and a micrel KSZ9031 phy. [ 146.195696] fec 2188000.ethernet eth0: MDIO read timeout [ 146.201779] ------------[ cut here ]------------ [ 146.206671] WARNING: CPU: 0 PID: 571 at drivers/net/phy/phy.c:942 phy_error+0x24/0x6c [ 146.214744] Modules linked in: bnep imx_vdoa imx_sdma evbug [ 146.220640] CPU: 0 PID: 571 Comm: irq/128-2188000 Not tainted 5.18.0-rc3-00080-gd569e86915b7 #9 [ 146.229563] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 146.236257] unwind_backtrace from show_stack+0x10/0x14 [ 146.241640] show_stack from dump_stack_lvl+0x58/0x70 [ 146.246841] dump_stack_lvl from __warn+0xb4/0x24c [ 146.251772] __warn from warn_slowpath_fmt+0x5c/0xd4 [ 146.256873] warn_slowpath_fmt from phy_error+0x24/0x6c [ 146.262249] phy_error from kszphy_handle_interrupt+0x40/0x48 [ 146.268159] kszphy_handle_interrupt from irq_thread_fn+0x1c/0x78 [ 146.274417] irq_thread_fn from irq_thread+0xf0/0x1dc [ 146.279605] irq_thread from kthread+0xe4/0x104 [ 146.284267] kthread from ret_from_fork+0x14/0x28 [ 146.289164] Exception stack(0xe6fa1fb0 to 0xe6fa1ff8) [ 146.294448] 1fa0: 00000000 00000000 00000000 00000000 [ 146.302842] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 146.311281] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 146.318262] irq event stamp: 12325 [ 146.321780] hardirqs last enabled at (12333): [<c01984c4>] __up_console_sem+0x50/0x60 [ 146.330013] hardirqs last disabled at (12342): [<c01984b0>] __up_console_sem+0x3c/0x60 [ 146.338259] softirqs last enabled at (12324): [<c01017f0>] __do_softirq+0x2c0/0x624 [ 146.346311] softirqs last disabled at (12319): [<c01300ac>] __irq_exit_rcu+0x138/0x178 [ 146.354447] ---[ end trace 0000000000000000 ]--- With the FEC driver phydev->adjust_link() calls fec_enet_adjust_link() calls fec_stop()/fec_restart() and both these function reset and temporary disable the FEC disrupting any MII transaction that could be happening at the same time. fec_enet_adjust_link() and phy_read() can be running at the same time when we have one additional interrupt before the phy_state_machine() is able to terminate. Thread 1 (phylib WQ) | Thread 2 (phy interrupt) | | phy_interrupt() <-- PHY IRQ | handle_interrupt() | phy_read() | phy_trigger_machine() | --> schedule phylib WQ | | phy_state_machine() | phy_check_link_status() | phy_link_change() | phydev->adjust_link() | fec_enet_adjust_link() | --> FEC reset | phy_interrupt() <-- PHY IRQ | phy_read() | Fix this by acquiring the phydev lock in phy_interrupt(). Link: https://lore.kernel.org/all/20220422152612.GA510015@francesco-nb.int.toradex.com/ Fixes: c974bdbc3e77 ("net: phy: Use threaded IRQ, to allow IRQ from sleeping devices") cc: <stable@vger.kernel.org> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220506060815.327382-1-francesco.dolcini@toradex.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> [fd: backport: adapt locking before did_interrupt()/ack_interrupt() callbacks removal ] Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2022-05-12mmc: rtsx: add 74 Clocks in power on flowRicky WU
commit 1f311c94aabdb419c28e3147bcc8ab89269f1a7e upstream. SD spec definition: "Host provides at least 74 Clocks before issuing first command" After 1ms for the voltage stable then start issuing the Clock signals if POWER STATE is MMC_POWER_OFF to MMC_POWER_UP to issue Clock signal to card MMC_POWER_UP to MMC_POWER_ON to stop issuing signal to card Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/1badf10aba764191a1a752edcbf90389@realtek.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Christian Loehle <cloehle@hyperstone.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12PCI: aardvark: Fix reading MSI interrupt numberPali Rohár
commit 805dfc18dd3d4dd97a987d4406593b5a225b1253 upstream. In advk_pcie_handle_msi() it is expected that when bit i in the W1C register PCIE_MSI_STATUS_REG is cleared, the PCIE_MSI_PAYLOAD_REG is updated to contain the MSI number corresponding to index i. Experiments show that this is not so, and instead PCIE_MSI_PAYLOAD_REG always contains the number of the last received MSI, overall. Do not read PCIE_MSI_PAYLOAD_REG register for determining MSI interrupt number. Since Aardvark already forbids more than 32 interrupts and uses own allocated hwirq numbers, the msi_idx already corresponds to the received MSI number. Link: https://lore.kernel.org/r/20220110015018.26359-3-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12PCI: aardvark: Clear all MSIs at setupPali Rohár
commit 7d8dc1f7cd007a7ce94c5b4c20d63a8b8d6d7751 upstream. We already clear all the other interrupts (ISR0, ISR1, HOST_CTRL_INT). Define a new macro PCIE_MSI_ALL_MASK and do the same clearing for MSIs, to ensure that we don't start receiving spurious interrupts. Use this new mask in advk_pcie_handle_msi(); Link: https://lore.kernel.org/r/20211130172913.9727-5-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12dm: interlock pending dm_io and dm_wait_for_bios_completionMike Snitzer
commit 9f6dc633761006f974701d4c88da71ab68670749 upstream. Commit d208b89401e0 ("dm: fix mempool NULL pointer race when completing IO") didn't go far enough. When bio_end_io_acct ends the count of in-flight I/Os may reach zero and the DM device may be suspended. There is a possibility that the suspend races with dm_stats_account_io. Fix this by adding percpu "pending_io" counters to track outstanding dm_io. Move kicking of suspend queue to dm_io_dec_pending(). Also, rename md_in_flight_bios() to dm_in_flight_bios() and update it to iterate all pending_io counters. Fixes: d208b89401e0 ("dm: fix mempool NULL pointer race when completing IO") Cc: stable@vger.kernel.org Co-developed-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12dm: fix mempool NULL pointer race when completing IOJiazi Li
commit d208b89401e073de986dc891037c5a668f5d5d95 upstream. dm_io_dec_pending() calls end_io_acct() first and will then dec md in-flight pending count. But if a task is swapping DM table at same time this can result in a crash due to mempool->elements being NULL: task1 task2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 ->dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [ 67.330330] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ...... [ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 67.330510] pc : mempool_free+0x70/0xa0 [ 67.330515] lr : mempool_free+0x4c/0xa0 [ 67.330520] sp : ffffff8008013b20 [ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004 [ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] x15: 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 0000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000 [ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a [ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001 [ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8 [ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970 [ 67.330609] Call trace: [ 67.330616] mempool_free+0x70/0xa0 [ 67.330627] bio_put+0xf8/0x110 [ 67.330638] dec_pending+0x13c/0x230 [ 67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.330716] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq+0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] cpuidle_enter_state+0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4/0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] secondary_start_kernel+0x160/0x170 Fix this by: 1) Establishing pointers to 'struct dm_io' members in dm_io_dec_pending() so that they may be passed into end_io_acct() _after_ free_io() is called. 2) Moving end_io_acct() after free_io(). Cc: stable@vger.kernel.org Signed-off-by: Jiazi Li <lijiazi@xiaomi.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpuFelix Kuehling
commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 upstream. amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap to access the BO through the corresponding file descriptor. The VM can also be extracted from drm_priv, so drm_priv can replace the vm parameter in the kfd2kgd interface. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [This is a partial cherry-pick of the upstream commit.] Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12smsc911x: allow using IRQ0Sergey Shtylyov
commit 5ef9b803a4af0f5e42012176889b40bb2a978b18 upstream. The AlphaProject AP-SH4A-3A/AP-SH4AD-0A SH boards use IRQ0 for their SMSC LAN911x Ethernet chip, so the networking on them must have been broken by commit 965b2aa78fbc ("net/smsc911x: fix irq resource allocation failure") which filtered out 0 as well as the negative error codes -- it was kinda correct at the time, as platform_get_irq() could return 0 on of_irq_get() failure and on the actual 0 in an IRQ resource. This issue was fixed by me (back in 2016!), so we should be able to fix this driver to allow IRQ0 usage again... When merging this to the stable kernels, make sure you also merge commit e330b9a6bb35 ("platform: don't return 0 from platform_get_irq[_byname]() on error") -- that's my fix to platform_get_irq() for the DT platforms... Fixes: 965b2aa78fbc ("net/smsc911x: fix irq resource allocation failure") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/656036e4-6387-38df-b8a7-6ba683b16e63@omp.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12bnxt_en: Fix possible bnxt_open() failure caused by wrong RFS flagSomnath Kotur
commit 13ba794397e45e52893cfc21d7a69cb5f341b407 upstream. bnxt_open() can fail in this code path, especially on a VF when it fails to reserve default rings: bnxt_open() __bnxt_open_nic() bnxt_clear_int_mode() bnxt_init_dflt_ring_mode() RX rings would be set to 0 when we hit this error path. It is possible for a subsequent bnxt_open() call to potentially succeed with a code path like this: bnxt_open() bnxt_hwrm_if_change() bnxt_fw_init_one() bnxt_fw_init_one_p3() bnxt_set_dflt_rfs() bnxt_rfs_capable() bnxt_hwrm_reserve_rings() On older chips, RFS is capable if we can reserve the number of vnics that is equal to RX rings + 1. But since RX rings is still set to 0 in this code path, we may mistakenly think that RFS is supported for 0 RX rings. Later, when the default RX rings are reserved and we try to enable RFS, it would fail and cause bnxt_open() to fail unnecessarily. We fix this in 2 places. bnxt_rfs_capable() will always return false if RX rings is not yet set. bnxt_init_dflt_ring_mode() will call bnxt_set_dflt_rfs() which will always clear the RFS flags if RFS is not supported. Fixes: 20d7d1c5c9b1 ("bnxt_en: reliably allocate IRQ table on reset to avoid crash") Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12net: emaclite: Add error handling for of_address_to_resource()Shravya Kumbham
commit 7a6bc33ab54923d325d9a1747ec9652c4361ebd1 upstream. check the return value of of_address_to_resource() and also add missing of_node_put() for np and npp nodes. Fixes: e0a3bc65448c ("net: emaclite: Support multiple phys connected to one MDIO bus") Addresses-Coverity: Event check_return value. Signed-off-by: Shravya Kumbham <shravya.kumbham@xilinx.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12net: stmmac: dwmac-sun8i: add missing of_node_put() in ↵Yang Yingliang
sun8i_dwmac_register_mdio_mux() commit 1a15267b7be77e0792cf0c7b36ca65c8eb2df0d8 upstream. The node pointer returned by of_get_child_by_name() with refcount incremented, so add of_node_put() after using it. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220428095716.540452-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12net: ethernet: mediatek: add missing of_node_put() in mtk_sgmii_init()Yang Yingliang
commit ff5265d45345d01fefc98fcb9ae891b59633c919 upstream. The node pointer returned by of_parse_phandle() with refcount incremented, so add of_node_put() after using it in mtk_sgmii_init(). Fixes: 9ffee4a8276c ("net: ethernet: mediatek: Extend SGMII related functions") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220428062543.64883-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12RDMA/siw: Fix a condition race issue in MPA request processingCheng Xu
commit ef91271c65c12d36e4c2b61c61d4849fb6d11aa0 upstream. The calling of siw_cm_upcall and detaching new_cep with its listen_cep should be atomistic semantics. Otherwise siw_reject may be called in a temporary state, e,g, siw_cm_upcall is called but the new_cep->listen_cep has not being cleared. This fixes a WARN: WARNING: CPU: 7 PID: 201 at drivers/infiniband/sw/siw/siw_cm.c:255 siw_cep_put+0x125/0x130 [siw] CPU: 2 PID: 201 Comm: kworker/u16:22 Kdump: loaded Tainted: G E 5.17.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: iw_cm_wq cm_work_handler [iw_cm] RIP: 0010:siw_cep_put+0x125/0x130 [siw] Call Trace: <TASK> siw_reject+0xac/0x180 [siw] iw_cm_reject+0x68/0xc0 [iw_cm] cm_work_handler+0x59d/0xe20 [iw_cm] process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 ? rescuer_thread+0x390/0x390 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Link: https://lore.kernel.org/r/d528d83466c44687f3872eadcb8c184528b2e2d4.1650526554.git.chengyou@linux.alibaba.com Reported-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Bernard Metzler <bmt@zurich.ibm.com> Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12hwmon: (adt7470) Fix warning on module removalArmin Wolf
commit 7b2666ce445c700b8dcee994da44ddcf050a0842 upstream. When removing the adt7470 module, a warning might be printed: do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffa006052b>] adt7470_update_thread+0x7b/0x130 [adt7470] This happens because adt7470_update_thread() can leave the kthread in TASK_INTERRUPTIBLE state when the kthread is being stopped before the call of set_current_state(). Since kthread_exit() might sleep in exit_signals(), the warning is printed. Fix that by using schedule_timeout_interruptible() and removing the call of set_current_state(). This causes TASK_INTERRUPTIBLE to be set after kthread_should_stop() which might cause the kthread to exit. Reported-by: Zheyu Ma <zheyuma97@gmail.com> Fixes: 93cacfd41f82 (hwmon: (adt7470) Allow faster removal) Signed-off-by: Armin Wolf <W_Armin@gmx.de> Tested-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220407101312.13331-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12nfc: nfcmrvl: main: reorder destructive operations in ↵Duoming Zhou
nfcmrvl_nci_unregister_dev to avoid bugs commit d270453a0d9ec10bb8a802a142fb1b3601a83098 upstream. There are destructive operations such as nfcmrvl_fw_dnld_abort and gpio_free in nfcmrvl_nci_unregister_dev. The resources such as firmware, gpio and so on could be destructed while the upper layer functions such as nfcmrvl_fw_dnld_start and nfcmrvl_nci_recv_frame is executing, which leads to double-free, use-after-free and null-ptr-deref bugs. There are three situations that could lead to double-free bugs. The first situation is shown below: (Thread 1) | (Thread 2) nfcmrvl_fw_dnld_start | ... | nfcmrvl_nci_unregister_dev release_firmware() | nfcmrvl_fw_dnld_abort kfree(fw) //(1) | fw_dnld_over | release_firmware ... | kfree(fw) //(2) | ... The second situation is shown below: (Thread 1) | (Thread 2) nfcmrvl_fw_dnld_start | ... | mod_timer | (wait a time) | fw_dnld_timeout | nfcmrvl_nci_unregister_dev fw_dnld_over | nfcmrvl_fw_dnld_abort release_firmware | fw_dnld_over kfree(fw) //(1) | release_firmware ... | kfree(fw) //(2) The third situation is shown below: (Thread 1) | (Thread 2) nfcmrvl_nci_recv_frame | if(..->fw_download_in_progress)| nfcmrvl_fw_dnld_recv_frame | queue_work | | fw_dnld_rx_work | nfcmrvl_nci_unregister_dev fw_dnld_over | nfcmrvl_fw_dnld_abort release_firmware | fw_dnld_over kfree(fw) //(1) | release_firmware | kfree(fw) //(2) The firmware struct is deallocated in position (1) and deallocated in position (2) again. The crash trace triggered by POC is like below: BUG: KASAN: double-free or invalid-free in fw_dnld_over Call Trace: kfree fw_dnld_over nfcmrvl_nci_unregister_dev nci_uart_tty_close tty_ldisc_kill tty_ldisc_hangup __tty_hangup.part.0 tty_release ... What's more, there are also use-after-free and null-ptr-deref bugs in nfcmrvl_fw_dnld_start. If we deallocate firmware struct, gpio or set null to the members of priv->fw_dnld in nfcmrvl_nci_unregister_dev, then, we dereference firmware, gpio or the members of priv->fw_dnld in nfcmrvl_fw_dnld_start, the UAF or NPD bugs will happen. This patch reorders destructive operations after nci_unregister_device in order to synchronize between cleanup routine and firmware download routine. The nci_unregister_device is well synchronized. If the device is detaching, the firmware download routine will goto error. If firmware download routine is executing, nci_unregister_device will wait until firmware download routine is finished. Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12can: grcan: use ofdev->dev when allocating DMA memoryDaniel Hellstrom
commit 101da4268626b00d16356a6bf284d66e44c46ff9 upstream. Use the device of the device tree node should be rather than the device of the struct net_device when allocating DMA buffers. The driver got away with it on sparc32 until commit 53b7670e5735 ("sparc: factor the dma coherent mapping into helper") after which the driver oopses. Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores") Link: https://lore.kernel.org/all/20220429084656.29788-2-andreas@gaisler.com Cc: stable@vger.kernel.org Signed-off-by: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12can: grcan: grcan_close(): fix deadlockDuoming Zhou
commit 47f070a63e735bcc8d481de31be1b5a1aa62b31c upstream. There are deadlocks caused by del_timer_sync(&priv->hang_timer) and del_timer_sync(&priv->rr_timer) in grcan_close(), one of the deadlocks are shown below: (Thread 1) | (Thread 2) | grcan_reset_timer() grcan_close() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | grcan_initiate_running_reset() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold priv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need priv->lock in position (2) of thread 2. As a result, grcan_close() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. Link: https://lore.kernel.org/all/20220425042400.66517-1-duoming@zju.edu.cn Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores") Cc: stable@vger.kernel.org Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12s390/dasd: Fix read inconsistency for ESE DASD devicesJan Höppner
commit b9c10f68e23c13f56685559a0d6fdaca9f838324 upstream. Read requests that return with NRF error are partially completed in dasd_eckd_ese_read(). The function keeps track of the amount of processed bytes and the driver will eventually return this information back to the block layer for further processing via __dasd_cleanup_cqr() when the request is in the final stage of processing (from the driver's perspective). For this, blk_update_request() is used which requires the number of bytes to complete the request. As per documentation the nr_bytes parameter is described as follows: "number of bytes to complete for @req". This was mistakenly interpreted as "number of bytes _left_ for @req" leading to new requests with incorrect data length. The consequence are inconsistent and completely wrong read requests as data from random memory areas are read back. Fix this by correctly specifying the amount of bytes that should be used to complete the request. Fixes: 5e6bdd37c552 ("s390/dasd: fix data corruption for thin provisioned devices") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20220505141733.1989450-5-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12s390/dasd: Fix read for ESE with blksize < 4kJan Höppner
commit cd68c48ea15c85f1577a442dc4c285e112ff1b37 upstream. When reading unformatted tracks on ESE devices, the corresponding memory areas are simply set to zero for each segment. This is done incorrectly for blocksizes < 4096. There are two problems. First, the increment of dst is done using the counter of the loop (off), which is increased by blksize every iteration. This leads to a much bigger increment for dst as actually intended. Second, the increment of dst is done before the memory area is set to 0, skipping a significant amount of bytes of memory. This leads to illegal overwriting of memory and ultimately to a kernel panic. This is not a problem with 4k blocksize because blk_queue_max_segment_size is set to PAGE_SIZE, always resulting in a single iteration for the inner segment loop (bv.bv_len == blksize). The incorrectly used 'off' value to increment dst is 0 and the correct memory area is used. In order to fix this for blksize < 4k, increment dst correctly using the blksize and only do it at the end of the loop. Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20220505141733.1989450-4-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12s390/dasd: prevent double format of tracks for ESE devicesStefan Haberland
commit 71f3871657370dbbaf942a1c758f64e49a36c70f upstream. For ESE devices we get an error for write operations on an unformatted track. Afterwards the track will be formatted and the IO operation restarted. When using alias devices a track might be accessed by multiple requests simultaneously and there is a race window that a track gets formatted twice resulting in data loss. Prevent this by remembering the amount of formatted tracks when starting a request and comparing this number before actually formatting a track on the fly. If the number has changed there is a chance that the current track was finally formatted in between. As a result do not format the track and restart the current IO to check. The number of formatted tracks does not match the overall number of formatted tracks on the device and it might wrap around but this is no problem. It is only needed to recognize that a track has been formatted at all in between. Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Link: https://lore.kernel.org/r/20220505141733.1989450-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12s390/dasd: fix data corruption for ESE devicesStefan Haberland
commit 5b53a405e4658580e1faf7c217db3f55a21ba849 upstream. For ESE devices we get an error when accessing an unformatted track. The handling of this error will return zero data for read requests and format the track on demand before writing to it. To do this the code needs to distinguish between read and write requests. This is done with data from the blocklayer request. A pointer to the blocklayer request is stored in the CQR. If there is an error on the device an ERP request is built to do error recovery. While the ERP request is mostly a copy of the original CQR the pointer to the blocklayer request is not copied to not accidentally pass it back to the blocklayer without cleanup. This leads to the error that during ESE handling after an ERP request was built it is not possible to determine the IO direction. This leads to the formatting of a track for read requests which might in turn lead to data corruption. Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Link: https://lore.kernel.org/r/20220505141733.1989450-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12ACPICA: Always create namespace nodes using acpi_ns_create_node()Vegard Nossum
commit 25928deeb1e4e2cdae1dccff349320c6841eb5f8 upstream. ACPICA commit 29da9a2a3f5b2c60420893e5c6309a0586d7a329 ACPI is allocating an object using kmalloc(), but then frees it using kmem_cache_free(<"Acpi-Namespace" kmem_cache>). This is wrong and can lead to boot failures manifesting like this: hpet0: 3 comparators, 64-bit 100.000000 MHz counter clocksource: Switched to clocksource tsc-early BUG: unable to handle page fault for address: 000000003ffe0018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0+ #211 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Code: 00 00 4c 8b 45 00 65 49 8b 50 08 65 4c 03 05 6f cc e7 7e 4d 8b 20 4d 85 e4 0f 84 3d 01 00 00 8b 45 20 48 8b 7d 00 48 8d 4a 01 <49> 8b 1c 04 4c 89 e0 65 48 0f c7 0f 0f 94 c0 84 c0 74 c5 8b 45 20 RSP: 0000:ffffc90000013df8 EFLAGS: 00010206 RAX: 0000000000000018 RBX: ffffffff81c49200 RCX: 0000000000000002 RDX: 0000000000000001 RSI: 0000000000000dc0 RDI: 000000000002b300 RBP: ffff88803e403d00 R08: ffff88803ec2b300 R09: 0000000000000001 R10: 0000000000000dc0 R11: 0000000000000006 R12: 000000003ffe0000 R13: ffffffff8110a583 R14: 0000000000000dc0 R15: ffffffff81c49a80 FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003ffe0018 CR3: 0000000001c0a001 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __trace_define_field+0x33/0xa0 event_trace_init+0xeb/0x2b4 tracer_init_tracefs+0x60/0x195 ? register_tracer+0x1e7/0x1e7 do_one_initcall+0x74/0x160 kernel_init_freeable+0x190/0x1f0 ? rest_init+0x9a/0x9a kernel_init+0x5/0xf6 ret_from_fork+0x35/0x40 CR2: 000000003ffe0018 ---[ end trace 707efa023f2ee960 ]--- RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Bisection leads to unrelated changes in slab; Vlastimil Babka suggests an unrelated layout or slab merge change merely exposed the underlying bug. Link: https://lore.kernel.org/lkml/4dc93ff8-f86e-f4c9-ebeb-6d3153a78d03@oracle.com/ Link: https://lore.kernel.org/r/a1461e21-c744-767d-6dfc-6641fd3e3ce2@siemens.com Link: https://github.com/acpica/acpica/commit/29da9a2a Fixes: f79c8e4136ea ("ACPICA: Namespace: simplify creation of the initial/default namespace") Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Diagnosed-by: Vlastimil Babka <vbabka@suse.cz> Diagnosed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12firewire: core: extend card->lock in fw_core_handle_bus_resetNiels Dossche
commit a7ecbe92b9243edbe94772f6f2c854e4142a3345 upstream. card->local_node and card->bm_retries are both always accessed under card->lock. fw_core_handle_bus_reset has a check whose condition depends on card->local_node and whose body writes to card->bm_retries. Both of these accesses are not under card->lock. Move the lock acquiring of card->lock to before this check such that these accesses do happen when card->lock is held. fw_destroy_nodes is called inside the check. Since fw_destroy_nodes already acquires card->lock inside its function body, move this out to the callsites of fw_destroy_nodes. Also add a comment to indicate which locking is necessary when calling fw_destroy_nodes. Cc: <stable@vger.kernel.org> Signed-off-by: Niels Dossche <dossche.niels@gmail.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20220409041243.603210-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12firewire: remove check of list iterator against head past the loop bodyJakob Koschel
commit 9423973869bd4632ffe669f950510c49296656e0 upstream. When list_for_each_entry() completes the iteration over the whole list without breaking the loop, the iterator value will be a bogus pointer computed based on the head element. While it is safe to use the pointer to determine if it was computed based on the head element, either with list_entry_is_head() or &pos->member == head, using the iterator variable after the loop should be avoided. In preparation to limit the scope of a list iterator to the list traversal loop, use a dedicated pointer to point to the found element [1]. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Cc: <stable@vger.kernel.org> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20220409041243.603210-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12firewire: fix potential uaf in outbound_phy_packet_callback()Chengfeng Ye
commit b7c81f80246fac44077166f3e07103affe6db8ff upstream. &e->event and e point to the same address, and &e->event could be freed in queue_event. So there is a potential uaf issue if we dereference e after calling queue_event(). Fix this by adding a temporary variable to maintain e->client in advance, this can avoid the potential uaf issue. Cc: <stable@vger.kernel.org> Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20220409041243.603210-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12gpiolib: of: fix bounds check for 'gpio-reserved-ranges'Andrei Lalaev
commit e75f88efac05bf4e107e4171d8db6d8c3937252d upstream. Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" because it clears "size" bits starting from the "start" bit in the according bitmap. So it has to use "greater" instead of "greater or equal" when performs bounds check to make sure that GPIOs are in the available range. Previous implementation skipped ranges that include the last GPIO in the range. I wrote the mail to the maintainers (https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u) of the questioned DTSes (because I couldn't understand how the maintainers interpreted this property), but I haven't received a response. Since the questioned DTSes use "gpio-reserved-ranges = <0 4>" (i.e., the beginning of the range), this patch doesn't affect these DTSes at all. TBH this patch doesn't break any existing DTSes because none of them reserve gpios at the end of range. Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-19 11:23:00 +0000