Update 5.4-2.1.x-imx to v5.4.63 from stable #125
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Enable ISI child device. Signed-off-by: Guoniu.zhou <[email protected]> Reviewed-by: Robby Cai <[email protected]>
…hannel@0 fsl,data-mapping property The lvds-channel@0 fsl,data-mapping property is wrongly moved out from lvds-channel@0 node to the parent ldb node by a previous commit. This patch fixes the property. Fixes: 46552df ("MLK-23694-12 arm64: dts: imx8mp-evk: integrate LVDS bridge display in") Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Fancy Fang <[email protected]>
…eck() Due to limited video PLL frequency points on i.MX8mp, the exact pixel clock rate of a panel's video mode is likely unsupported by the clock tree. The driver would take a slightly fixed up pixel clock rate to match with the clock tree capability and the panel should still work with that. This should work based on the agreement that the chosen panel should work with the existing PLL frequency points. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Fancy Fang <[email protected]>
Set regmap to use regcache only in probe in order to avoid issue on cat /sys/kernel/debug/regmap/30cc0000.xcvr/registers Signed-off-by: Viorel Suman <[email protected]> Reviewed-by: Shengjiu Wang <[email protected]>
A power domain associated with a device may be disabled in a separate thread by "genpd_power_off_work_fn" function in case the device has no PM runtime enabled at that moment. This will stop the parent clock of "bus" clk and hang the probe in regmap read/write operation. In order to avoid this PM runtime must be enabled before any regmap read/write ops. Aside of this replace clk bus clocks with pm_runtime_get/put_sync calls. Signed-off-by: Viorel Suman <[email protected]> Fixes: c2641e1 ("MLK-23618-9: ASoC: fsl_sai: Don't bind clock with regmap") Reviewed-by: Shengjiu Wang <[email protected]>
Provide dev in clk_register in order to allow subsequent power domain management. Signed-off-by: Shengjiu Wang <[email protected]> Signed-off-by: Viorel Suman <[email protected]> Reviewed-by: Abel Vesa <[email protected]>
Move clock management and registers reads/writes into runtime PM callbacks. Signed-off-by: Viorel Suman <[email protected]> Reviewed-by: Shengjiu Wang <[email protected]> Reviewed-by: Abel Vesa <[email protected]>
The function snvs_reader uses a switch case with intentionnal fall through which is an error displayed at compilation. This patch uses the keyword "fallthrough" to fix the issue. Signed-off-by: Franck LENORMAND <[email protected]> Reviewed-by: Horia Geantă <[email protected]>
Fix the warn dump of the device driver bound link. Indroduced by kernel updates "515db266a9dace92b0cbaed9a6044dd5304b8ca9" Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Fugang Duan <[email protected]>
Since the typec port data role is separated from power role, so check the port data capability when setting data role. Signed-off-by: Li Jun <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 6ecc632)
Update GPU database. And fix VSI profiler GPU hang issue, also update power management register for VIP. Signed-off-by: Ella Feng <[email protected]>
Initialize the variable value to fix build warning. CC drivers/pci/controller/dwc/pci-imx6.o drivers/pci/controller/dwc/pci-imx6.c: In function ‘imx6_pcie_probe’: drivers/pci/controller/dwc/pci-imx6.c:2676:5: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Fugang Duan <[email protected]>
It is possible that the regulator_get will return defer probe error if the regulator is not ready when cpufreq doing probe. cpufreq need to defer probe again if regulator_get return '-EPROBE_DEFER', so fix it. Signed-off-by: Jacky Bai <[email protected]> Reviewed-by: Anson Huang <[email protected]>
Split sdma_init_sw and sdma_init_hw from sdma_init, so that sdma_init_hw could be delayed in channel allocate phase and it's easier for implementing runtime suspend/resume in the next. Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Shengjiu Wang <[email protected]>
Add runtime suspend/resume support on i.mx8mp. So sdma will be initialized and firmware will be loaded at first channel requested, sdma will be off once no any channel is running.For the legacy chips just keep sdma on always as before. Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Shengjiu Wang <[email protected]>
Add sdma_get_firmware_wait() since sdma firmware have to be ready after runtime resume. That could be done for runtime feature on i.mx8mp since the only sdma client audio driver request sdma channel after rootfs mounted which means no any block in sdma_get_firmware_wait() as sdma_get_firmware(). Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Shengjiu Wang <[email protected]>
Enable snvs_pwrkey on imx8mn-evk board. Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Anson Huang <[email protected]>
Enable snvs_pwrkey on imx8mm-ddr4-evk board. Signed-off-by: Robin Gong <[email protected]> Reviewed-by: Anson Huang <[email protected]>
No one is using the LVDS_BIT_MAP_SPWG/JEIDA enums, so remove them. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
…in enc->disable() Both of the two LVDS channels should be disabled for split mode in enc->disable(). Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
Instead of looking at ldb_ctrl to determine whether split mode is enabled or not, we may cache it in struct imx_ldb directly so that it can be accessed easily. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
This patch adds Freescale i.MX LVDS display bridge driver. The driver would add a common drm bridge which can be attached to platform specific LDB encoder drivers. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
This patch creates platform specific LDB encoder drivers for i.MX53, i.MX6qdl, i.MX8qm, i.MX8qxp and i.MX8mp. The encoders would attach the bridge added in Freescale i.MX LVDS display bridge driver. This way, the platform specific things can be handled in different drivers, like special phy settings, clocks and SCU misc settings, etc. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
This patch builds in FSL IMX LVDS bridge driver by default. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
…drivers This patch builds in Mixel LVDS (combo) PHY drivers by default. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
…der drivers This patch builds in i.MX8qm/qxp/mp LDB encoder drivers by default. Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Sandor Yu <[email protected]>
The call flow:
devm_regmap_init_mmio_clk
- clk_prepare()
- clk_pm_runtime_get()
Cause the power domain of bus clock always be enabled.
which impact the power consumption.
So we can't bind clock with regmap, then explicitly enable
clock when using.
Signed-off-by: Shengjiu Wang <[email protected]>
Reviewed-by: Viorel Suman <[email protected]>
With imx-pcm-dma, the dma channel is created in probe, when there is power domain attached with dma device, the power domain will be enabled when channel is created, then the power of the domain will be always enabled from beginning. So switch to imx-pcm-dma-v2, then the dma channel will be created when playback or capture really started. Signed-off-by: Shengjiu Wang <[email protected]> Reviewed-by: Viorel Suman <[email protected]>
The call flow:
devm_regmap_init_mmio_clk
- clk_prepare()
- clk_pm_runtime_get()
Cause the power domain of mem clock always be enabled.
which impact the power consumption.
so we can't bind clock with regmap, but explicitly enable
clock when using.
Signed-off-by: Shengjiu Wang <[email protected]>
Reviewed-by: Viorel Suman <[email protected]>
The call flow:
devm_regmap_init_mmio_clk
- clk_prepare()
- clk_pm_runtime_get()
Cause the power domain of ipg clock always be enabled.
which impact the power consumption.
so we can't bind clock with regmap, but explicitly enable
clock when using.
Signed-off-by: Shengjiu Wang <[email protected]>
Reviewed-by: Viorel Suman <[email protected]>
Change OCOTP node name from ocotp-ctrl to efuse to be compliant with yaml schema, it requires the nodename to be one of "eeprom|efuse|nvram". Signed-off-by: Anson Huang <[email protected]> Reviewed-by: Fugang Duan <[email protected]> Signed-off-by: Shawn Guo <[email protected]> (cherry picked from commit 12fa107) Signed-off-by: Andrey Zhizhikin <[email protected]>
Add "fsl,imx8mm-ocotp" as fallback compatible of i.MX8MP ocotp to support SoC serial_number read. Signed-off-by: Anson Huang <[email protected]> Signed-off-by: Shawn Guo <[email protected]> (cherry picked from commit f2fe45d) Signed-off-by: Andrey Zhizhikin <[email protected]>
Cherry-pick commits from linux-master onto 5.4-2.1.x-imx (SoC Serial Number -related)
This is the 5.4.62 stable release Conflicts (manual resolve): - drivers/usb/dwc3/gadget.c Fix a hickup during applying of the patch 4bc5d90 from upstream, that version is taken over the NXP one. Signed-off-by: Andrey Zhizhikin <[email protected]>
Update 5.4-2.1.x-imx to v5.4.62 from stable
commit bce1305 upstream. It appears that a ReportSize value of zero is legal, even if a bit non-sensical. Most of the HID code seems to handle that gracefully, except when computing the total size in bytes. When fed as input to memset, this leads to some funky outcomes. Detect the corner case and correctly compute the size. Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 35556be upstream. When calling into hid_map_usage(), the passed event code is blindly stored as is, even if it doesn't fit in the associated bitmap. This event code can come from a variety of sources, including devices masquerading as input devices, only a bit more "programmable". Instead of taking the event code at face value, check that it actually fits the corresponding bitmap, and if it doesn't: - spit out a warning so that we know which device is acting up - NULLify the bitmap pointer so that we catch unexpected uses Code paths that can make use of untrusted inputs can now check that the mapping was indeed correct and bail out if not. Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…ation commit e48a73a upstream. Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fda ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexey Budankov <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jin Yao <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paul Clarke <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Tony Jones <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d7c5782 upstream. Fix a static code checker warning. v2: Drop PTR_ERR_OR_ZERO. Signed-off-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Emily Deng <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: Walter Lozano <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f232d9e upstream. As seen in the Vivante kernel driver, most GPUs with the BLT engine have a broken TS cache flush. The workaround is to temporarily set the BLT command to CLEAR_IMAGE, without actually executing the clear. Apparently this state change is enough to trigger the required TS cache flush. As the BLT engine is completely asychronous, we also need a few more stall states to synchronize the flush with the frontend. Root-caused-by: Jonathan Marek <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Cc: Walter Lozano <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e9ee186 upstream. KVM has a one instruction window where it will allow an SError exception to be consumed by the hypervisor without treating it as a hypervisor bug. This is used to consume asynchronous external abort that were caused by the guest. As we are about to add another location that survives unexpected exceptions, generalise this code to make it behave like the host's extable. KVM's version has to be mapped to EL2 to be accessible on nVHE systems. The SError vaxorcism code is a one instruction window, so has two entries in the extable. Because the KVM code is copied for VHE and nVHE, we end up with four entries, half of which correspond with code that isn't mapped. Cc: <[email protected]> # 5.4.x Signed-off-by: James Morse <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 88a84cc upstream. KVM doesn't expect any synchronous exceptions when executing, any such exception leads to a panic(). AT instructions access the guest page tables, and can cause a synchronous external abort to be taken. The arm-arm is unclear on what should happen if the guest has configured the hardware update of the access-flag, and a memory type in TCR_EL1 that does not support atomic operations. B2.2.6 "Possible implementation restrictions on using atomic instructions" from DDI0487F.a lists synchronous external abort as a possible behaviour of atomic instructions that target memory that isn't writeback cacheable, but the page table walker may behave differently. Make KVM robust to synchronous exceptions caused by AT instructions. Add a get_user() style helper for AT instructions that returns -EFAULT if an exception was generated. While KVM's version of the exception table mixes synchronous and asynchronous exceptions, only one of these can occur at each location. Re-enter the guest when the AT instructions take an exception on the assumption the guest will take the same exception. This isn't guaranteed to make forward progress, as the AT instructions may always walk the page tables, but guest execution may use the translation cached in the TLB. This isn't a problem, as since commit 5dcd0fd ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: [email protected] # <v5.3: 5dcd0fd ("KVM: arm64: Defer guest entry when an asynchronous exception is pending") Signed-off-by: James Morse <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 71a7f8c upstream. AT instructions do a translation table walk and return the result, or the fault in PAR_EL1. KVM uses these to find the IPA when the value is not provided by the CPU in HPFAR_EL1. If a translation table walk causes an external abort it is taken as an exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11 "Synchronous faults generated by address translation instructions") While we previously made KVM resilient to exceptions taken due to AT instructions, the device access causes mismatched attributes, and may occur speculatively. Prevent this, by forbidding a walk through memory described as device at stage2. Now such AT instructions will report a stage2 fault. Such a fault will cause KVM to restart the guest. If the AT instructions always walk the page tables, but guest execution uses the translation cached in the TLB, the guest can't make forward progress until the TLB entry is evicted. This isn't a problem, as since commit 5dcd0fd ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: [email protected] # <v5.3: 5dcd0fd ("KVM: arm64: Defer guest entry when an asynchronous exception is pending") Signed-off-by: James Morse <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f7f86e8 upstream. commit b5a84ec ("mmc: tegra: Add Tegra210 support") Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data timeout. So, this patch adds "tmclk" to Tegra sdhci clock property in the device tree binding. Fixes: b5a84ec ("mmc: tegra: Add Tegra210 support") Cc: stable <[email protected]> # 5.4 Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c956c0c upstream. commit 5425fb1 ("arm64: tegra: Add Tegra194 chip device tree") Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 5425fb1 ("arm64: tegra: Add Tegra194 chip device tree") Cc: stable <[email protected]> # 5.4 Tested-by: Jon Hunter <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit baba217 upstream. commit 39cb62c ("arm64: tegra: Add Tegra186 support") Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host capability register and uses it by default. So, this clock should be kept enabled by the SDMMC driver. Fixes: 39cb62c ("arm64: tegra: Add Tegra186 support") Cc: stable <[email protected]> # 5.4 Tested-by: Jon Hunter <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 679f71f upstream. commit 742af7e ("arm64: tegra: Add Tegra210 support") Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 742af7e ("arm64: tegra: Add Tegra210 support") Cc: stable <[email protected]> # 5.4 Tested-by: Jon Hunter <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e33588a upstream. commit b5a84ec ("mmc: tegra: Add Tegra210 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the beginning of Tegra210 support in the driver. Tegra210 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra210. Fixes: b5a84ec ("mmc: tegra: Add Tegra210 support") Cc: stable <[email protected]> # 5.4 Tested-by: Jon Hunter <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Acked-by: Adrian Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 391d89d upstream. commit 4346b7c ("mmc: tegra: Add Tegra186 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the beginning of its support in driver. Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra186. Fixes: 4346b7c ("mmc: tegra: Add Tegra186 support") Cc: stable <[email protected]> # 5.4 Tested-by: Jon Hunter <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Acked-by: Adrian Hunter <[email protected]> Signed-off-by: Sowjanya Komatineni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8c4e0f2 upstream. 1) If remaining ring space before the end of the ring is smaller then the next cmd to write, tcmu writes a padding entry which fills the remaining space at the end of the ring. Then tcmu calls tcmu_flush_dcache_range() with the size of struct tcmu_cmd_entry as data length to flush. If the space filled by the padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is called for an address range reaching behind the end of the vmalloc'ed ring. tcmu_flush_dcache_range() in a loop calls flush_dcache_page(virt_to_page(start)); for every page being part of the range. On x86 the line is optimized out by the compiler, as flush_dcache_page() is empty on x86. But I assume the above can cause trouble on other architectures that really have a flush_dcache_page(). For paddings only the header part of an entry is relevant due to alignment rules the header always fits in the remaining space, if padding is needed. So tcmu_flush_dcache_range() can safely be called with sizeof(entry->hdr) as the length here. 2) After it has written a command to cmd ring, tcmu calls tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as data length to flush. But if a command needs many iovecs, the real size of the command may be bigger then tcmu_cmd_entry, so a part of the written command is not flushed then. Link: https://lore.kernel.org/r/[email protected] Acked-by: Mike Christie <[email protected]> Signed-off-by: Bodo Stroesser <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3c58f73 upstream. (scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/[email protected] Tested-by: JiangYu <[email protected]> Tested-by: Daniel Meyerholt <[email protected]> Acked-by: Mike Christie <[email protected]> Signed-off-by: Bodo Stroesser <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Tested-by: Shuah Khan <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This is the 5.4.63 stable release Signed-off-by: Andrey Zhizhikin <[email protected]>
|
Wrong branch :-) |
|
I need some holidays... 😃 Would re-submit to point to a correct one. -- andrey |
zandrey
pushed a commit
to zandrey/linux-fslc
that referenced
this pull request
Jan 27, 2022
…ed bind() commit dded089 upstream. Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 Freescale#125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: [email protected] Fixes: b874dec ("NFC: Implement LLCP connection less Tx path") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
zandrey
pushed a commit
to zandrey/linux-fslc
that referenced
this pull request
Jan 27, 2022
…ed bind() commit dded089 upstream. Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 Freescale#125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: [email protected] Fixes: b874dec ("NFC: Implement LLCP connection less Tx path") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
zandrey
pushed a commit
to zandrey/linux-fslc
that referenced
this pull request
Feb 1, 2022
…ed bind() commit dded089 upstream. Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 Freescale#125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: [email protected] Fixes: b874dec ("NFC: Implement LLCP connection less Tx path") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
angolini
pushed a commit
to angolini/linux-fslc
that referenced
this pull request
Sep 18, 2024
commit 177e1cc upstream. The start_kthread() and stop_thread() code was not always called with the interface_lock held. This means that the kthread variable could be unexpectedly changed causing the kthread_stop() to be called on it when it should not have been, leading to: while true; do rtla timerlat top -u -q & PID=$!; sleep 5; kill -INT $PID; sleep 0.001; kill -TERM $PID; wait $PID; done Causing the following OOPS: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [Freescale#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty Freescale#125 a533010b71dab205ad2f507188ce8c82203b0254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:hrtimer_active+0x58/0x300 Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f RSP: 0018:ffff88811d97f940 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28 RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60 R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28 FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0 Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x154/0x230 ? asm_exc_general_protection+0x26/0x30 ? hrtimer_active+0x58/0x300 ? __pfx_mutex_lock+0x10/0x10 ? __pfx_locks_remove_file+0x10/0x10 hrtimer_cancel+0x15/0x40 timerlat_fd_release+0x8e/0x1f0 ? security_file_release+0x43/0x80 __fput+0x372/0xb10 task_work_run+0x11e/0x1f0 ? _raw_spin_lock+0x85/0xe0 ? __pfx_task_work_run+0x10/0x10 ? poison_slab_object+0x109/0x170 ? do_exit+0x7a0/0x24b0 do_exit+0x7bd/0x24b0 ? __pfx_migrate_enable+0x10/0x10 ? __pfx_do_exit+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x64/0x140 ? _raw_spin_lock_irq+0x86/0xe0 do_group_exit+0xb0/0x220 get_signal+0x17ba/0x1b50 ? vfs_read+0x179/0xa40 ? timerlat_fd_read+0x30b/0x9d0 ? __pfx_get_signal+0x10/0x10 ? __pfx_timerlat_fd_read+0x10/0x10 arch_do_signal_or_restart+0x8c/0x570 ? __pfx_arch_do_signal_or_restart+0x10/0x10 ? vfs_read+0x179/0xa40 ? ksys_read+0xfe/0x1d0 ? __pfx_ksys_read+0x10/0x10 syscall_exit_to_user_mode+0xbc/0x130 do_syscall_64+0x74/0x110 ? __pfx___rseq_handle_notify_resume+0x10/0x10 ? __pfx_ksys_read+0x10/0x10 ? fpregs_restore_userregs+0xdb/0x1e0 ? fpregs_restore_userregs+0xdb/0x1e0 ? syscall_exit_to_user_mode+0x116/0x130 ? do_syscall_64+0x74/0x110 ? do_syscall_64+0x74/0x110 ? do_syscall_64+0x74/0x110 entry_SYSCALL_64_after_hwframe+0x71/0x79 RIP: 0033:0x7ff0070eca9c Code: Unable to access opcode bytes at 0x7ff0070eca72. RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003 RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0 R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003 R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008 </TASK> Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core ---[ end trace 0000000000000000 ]--- This is because it would mistakenly call kthread_stop() on a user space thread making it "exit" before it actually exits. Since kthreads are created based on global behavior, use a cpumask to know when kthreads are running and that they need to be shutdown before proceeding to do new work. Link: https://lore.kernel.org/all/[email protected]/ This was debugged by using the persistent ring buffer: Link: https://lore.kernel.org/all/[email protected]/ Note, locking was originally used to fix this, but that proved to cause too many deadlocks to work around: https://lore.kernel.org/linux-trace-kernel/[email protected]/ Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: "Luis Claudio R. Goncalves" <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: e88ed22 ("tracing/timerlat: Add user-space interface") Reported-by: Tomas Glozar <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automatic merge performed, no conflicts reported.
Build and boot tested on imx8mmevk, result - Pass.
-- andrey