March 2022 - Linux-stable-mirror

stable-rc/queue/5.4 build: 150 builds: 2 failed, 148 passed (v5.4.185-43-g6c27769e1413)

by kernelci.org bot

stable-rc/queue/5.4 build: 150 builds: 2 failed, 148 passed (v5.4.185-43-g6c27769e1413) Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F5.4/kernel/v5.4.185-43-… Tree: stable-rc Branch: queue/5.4 Git Describe: v5.4.185-43-g6c27769e1413 Git Commit: 6c27769e1413d0dc612dc1347f79d80adf6b2e37 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 7 unique architectures Build Failures Detected: arm: rpc_defconfig: (gcc-10) FAIL mips: ip28_defconfig: (gcc-10) FAIL --- For more info write to <info(a)kernelci.org>

2 years, 9 months

1
0
0 0

stable-rc/linux-4.19.y build: 196 builds: 6 failed, 190 passed (v4.19.235-23-g57e593a4ee92)

by kernelci.org bot

stable-rc/linux-4.19.y build: 196 builds: 6 failed, 190 passed (v4.19.235-23-g57e593a4ee92) Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.235-2… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.235-23-g57e593a4ee92 Git Commit: 57e593a4ee92b5fddbab3367340e9cb0300cc241 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 7 unique architectures Build Failures Detected: arm: rpc_defconfig: (gcc-10) FAIL mips: ip27_defconfig: (gcc-10) FAIL ip28_defconfig: (gcc-10) FAIL riscv: allnoconfig: (gcc-10) FAIL defconfig: (gcc-10) FAIL tinyconfig: (gcc-10) FAIL --- For more info write to <info(a)kernelci.org>

2 years, 9 months

1
0
0 0

Regression in 5.10.67: "iwlwifi: pcie: free RBs during configure" causes rx lockups with BAR_FRAME_RELEASE on AX200/AX201 when using 802.11ax

by Thorsten Leemhuis

Hi, this is your Linux kernel regression tracker. I noticed a regression report in bugzilla.kernel.org that afaics nobody acted upon since it was reported more than ten days ago (it afaifcs only later became clear this is a regression), that's why I decided to forward it to the lists and a few relevant people to the CC. To quote from https://bugzilla.kernel.org/show_bug.cgi?id=215660: > Stephane Poignant 2022-03-04 17:24:49 UTC > > Created attachment 300529 [details] > lspci and ethtool outputs on reproducing systems > > Context: > - dense enterprise deployment, 10 lightweight aps (Aruba) on one office floor, up to 125 concurrent users total, up to 25 user per AP > - the wireless network supports 802.11n, 802.11ac and 802.11ax in 5 GHz band > - authentication is wpa2-psk > - client devices consists in a variety of endpoints (laptops, cell phones, tablets, smart devices), running various versions of Mac OSX, Linux, Windows, Android or IOS. > - certain clients supports only 20Mhz, HT protection kicks in and turns off on APs as those clients are moving around. Consequently ht_operation_mode fluctuates between 4 and 6 even when staying on the same AP. > - the issue affects various laptops with Intel AX200 or AX201 chipsets, running Debian or Ubuntu with a recent kernel >= 5.10 > - see attached file devices.txt for detailed information on the different laptops we have reproduced the issue on > > > Steps to reproduce: > - appears sometimes, but not always, after the iwlwifi STA roams from one AP to another > - seen more often when ht_operation_mode changes between 4 and 6 (but not sufficient to trigger the issue) > - STA deassociates from current AP and associates to the new one successfully > - connectivity works on the new AP for a short period of time, usually between 30s and 1 minute > - then suddenly, the Rx path breaks. No more received frame visible on the STA wireless interface. AP reports that frames are retransmitted and not acknowledged by STA. > - the Tx path keeps working. Frames sent by STA to AP are received and visible on the network > - in this state each inbound frame appears to trigger iwl_pcie_rx_handle_rb with cmd BAR_FRAME_RELEASE (seqnum is always the same): > > Mar 4 12:44:32 debian kernel: [15884.715812] iwlwifi 0000:00:14.3: iwl_pcie_rx_handle Q 0: HW = 338, SW = 337 > Mar 4 12:44:32 debian kernel: [15884.715819] iwlwifi 0000:00:14.3: iwl_pcie_get_rxb Got virtual RB ID 1348 > Mar 4 12:44:32 debian kernel: [15884.715831] iwlwifi 0000:00:14.3: iwl_pcie_rx_handle_rb Q 0: cmd at offset 0: BAR_FRAME_RELEASE (00.c2, seq 0xbfff) > Mar 4 12:44:32 debian kernel: [15884.715838] iwlwifi 0000:00:14.3: iwl_mvm_release_frames_from_notif Frame release notification for BAID 14, NSSN 169 > Mar 4 12:44:32 debian kernel: [15884.715843] iwlwifi 0000:00:14.3: iwl_pcie_rx_handle_rb Q 0: RB end marker at offset 64 > Mar 4 12:44:32 debian kernel: [15884.715852] iwlwifi 0000:00:14.3: iwl_pcie_restock_bd Assigned virtual RB ID 1348 to queue 0 index 334 > > - those events do not appear during normal operation (or very rarely) > > > Temporary resolution: > - in most cases, the STA remains in this state until Wifi is restarted or until it roams to another AP > - while in that state, it may happens (rarely) that a few frame are received with very high latency, then the next ones are lost, for instance: > > [1646398334.114200] From 10.200.2.67 icmp_seq=148 Destination Host Unreachable > [1646398334.114242] From 10.200.2.67 icmp_seq=149 Destination Host Unreachable > [1646398334.114251] From 10.200.2.67 icmp_seq=150 Destination Host Unreachable > [1646398336.365181] 64 bytes from 10.200.2.1: icmp_seq=151 ttl=64 time=2251 ms > [1646398336.365237] 64 bytes from 10.200.2.1: icmp_seq=152 ttl=64 time=1227 ms > [1646398336.365250] 64 bytes from 10.200.2.1: icmp_seq=153 ttl=64 time=203 ms > [1646398375.042236] From 10.200.2.67 icmp_seq=188 Destination Host Unreachable > [1646398375.042291] From 10.200.2.67 icmp_seq=189 Destination Host Unreachable > [1646398375.042303] From 10.200.2.67 icmp_seq=190 Destination Host Unreachable > > > Workaround: > - disable_11ax=1 prevents the problem from happening > [...] > Stephane Poignant 2022-03-10 14:48:39 UTC > > Did some further testing with vanilla kernel. > 5.10.66 and older DO NOT reproduce the issue. > 5.10.67 and newer DO reproduce. > > I see the following changes according to changelog: > iwlwifi: mvm: Fix scan channel flags settings > iwlwifi: fw: correctly limit to monitor dump > iwlwifi: mvm: fix access to BSS elements > iwlwifi: mvm: avoid static queue number aliasing > iwlwifi: mvm: fix a memory leak in iwl_mvm_mac_ctxt_beacon_changed > iwlwifi: pcie: free RBs during configure > > Suspecting the one related with queues but no strong opinion atm. > > [reply] [−] Comment 6 Stephane Poignant 2022-03-11 10:18:29 UTC > > Ok so after some further testing, turned out that after commenting the following lines in file drivers/net/wireless/intel/iwlwifi/pcie/trans.c: > > /* free all first - we might be reconfigured for a different size */ > iwl_pcie_free_rbs_pool(trans); > > Which were introduced by the following commit: > iwlwifi: pcie: free RBs during configure > https://lore.kernel.org/all/iwlwifi.20210802170640.42d7c93279c4.I07f74e65aa… > > Then i'm no longer able to reproduce. Tested in vanilla 5.10.67, vanilla 5.10.88 and 5.10.92 with Debian patches. > Could somebody take a look into this? Or was this discussed somewhere else already? Or even fixed? Anyway, to get this tracked: #regzbot introduced: 608c8359c567b4a04dedbe #regzbot from: Stephane Poignant <stephane.poignant(a)proton.ch> #regzbot title: wireless: iwlwifi: regression in 5.10.67 due to "iwlwifi: pcie: free RBs during configure" #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215660 Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. -- Additional information about regzbot: If you want to know more about regzbot, check out its web-interface, the getting start guide, and the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md The last two documents will explain how you can interact with regzbot yourself if your want to. Hint for reporters: when reporting a regression it's in your interest to CC the regression list and tell regzbot about the issue, as that ensures the regression makes it onto the radar of the Linux kernel's regression tracker -- that's in your interest, as it ensures your report won't fall through the cracks unnoticed. Hint for developers: you normally don't need to care about regzbot once it's involved. Fix the issue as you normally would, just remember to include 'Link:' tag in the patch descriptions pointing to all reports about the issue. This has been expected from developers even before regzbot showed up for reasons explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'.

2 years, 9 months

1
1
0 0

Danke

by Michelle

Hallo, ich hoffe du hast meine Nachricht erhalten. Ich brauche schnelle Antworten Danke. Michelle

2 years, 9 months

1
0
0 0

[PATCH] mmc: sdhci-xenon: fix 1.8v regulator stabilization

by Marcin Wojtas

From: Alex Leibovich <alexl(a)marvell.com> Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platfroms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich <alexl(a)marvell.com> Signed-off-by: Marcin Wojtas <mw(a)semihalf.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/host/sdhci-xenon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c index c67611fdaa8a..4b05f6fdefb4 100644 --- a/drivers/mmc/host/sdhci-xenon.c +++ b/drivers/mmc/host/sdhci-xenon.c @@ -168,7 +168,12 @@ static void xenon_reset_exit(struct sdhci_host *host, /* Disable tuning request and auto-retuning again */ xenon_retune_setup(host); - xenon_set_acg(host, true); + /* + * The ACG should be turned off at the early init time, in order + * to solve a possile issues with the 1.8V regulator stabilization. + * The feature is enabled in later stage. + */ + xenon_set_acg(host, false); xenon_set_sdclk_off_idle(host, sdhc_id, false); -- 2.29.0

2 years, 9 months

4
10
0 0

patch "mei: avoid iterator usage outside of list_for_each_entry" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: avoid iterator usage outside of list_for_each_entry to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From c10187b1c5ebb8681ca467ab7b0ded5ea415d258 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Tue, 8 Mar 2022 11:59:26 +0200 Subject: mei: avoid iterator usage outside of list_for_each_entry Usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Do not reference the loop variable outside of the loop, by rearranging the orders of execution. Instead of performing search loop and checking outside the loop if the end of the list was hit and no matching element was found, the execution is performed inside the loop upon a successful match followed by a goto statement to the next step, therefore no condition has to be performed after the loop has ended. Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20220308095926.300412-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/interrupt.c | 35 +++++++++++++++-------------------- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c index a67f4f2d33a9..0706322154cb 100644 --- a/drivers/misc/mei/interrupt.c +++ b/drivers/misc/mei/interrupt.c @@ -424,31 +424,26 @@ int mei_irq_read_handler(struct mei_device *dev, list_for_each_entry(cl, &dev->file_list, link) { if (mei_cl_hbm_equal(cl, mei_hdr)) { cl_dbg(dev, cl, "got a message\n"); - break; + ret = mei_cl_irq_read_msg(cl, mei_hdr, meta_hdr, cmpl_list); + goto reset_slots; } } /* if no recipient cl was found we assume corrupted header */ - if (&cl->link == &dev->file_list) { - /* A message for not connected fixed address clients - * should be silently discarded - * On power down client may be force cleaned, - * silently discard such messages - */ - if (hdr_is_fixed(mei_hdr) || - dev->dev_state == MEI_DEV_POWER_DOWN) { - mei_irq_discard_msg(dev, mei_hdr, mei_hdr->length); - ret = 0; - goto reset_slots; - } - dev_err(dev->dev, "no destination client found 0x%08X\n", - dev->rd_msg_hdr[0]); - ret = -EBADMSG; - goto end; + /* A message for not connected fixed address clients + * should be silently discarded + * On power down client may be force cleaned, + * silently discard such messages + */ + if (hdr_is_fixed(mei_hdr) || + dev->dev_state == MEI_DEV_POWER_DOWN) { + mei_irq_discard_msg(dev, mei_hdr, mei_hdr->length); + ret = 0; + goto reset_slots; } - - ret = mei_cl_irq_read_msg(cl, mei_hdr, meta_hdr, cmpl_list); - + dev_err(dev->dev, "no destination client found 0x%08X\n", dev->rd_msg_hdr[0]); + ret = -EBADMSG; + goto end; reset_slots: /* reset the number of slots and header */ -- 2.35.1

2 years, 9 months

1
0
0 0

patch "mei: me: add Alder Lake N device id." added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add Alder Lake N device id. to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 7bbbd0845818cffa9fa8ccfe52fa1cad58e7e4f2 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Tue, 1 Mar 2022 09:11:15 +0200 Subject: mei: me: add Alder Lake N device id. Add Alder Lake N device ID. Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20220301071115.96145-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 1 + drivers/misc/mei/pci-me.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index 888c27bc3f1a..64ce3f830262 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -107,6 +107,7 @@ #define MEI_DEV_ID_ADP_S 0x7AE8 /* Alder Lake Point S */ #define MEI_DEV_ID_ADP_LP 0x7A60 /* Alder Lake Point LP */ #define MEI_DEV_ID_ADP_P 0x51E0 /* Alder Lake Point P */ +#define MEI_DEV_ID_ADP_N 0x54E0 /* Alder Lake Point N */ /* * MEI HW Section diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index a05cdb25d0c4..33e58821e478 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -114,6 +114,7 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_ADP_S, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_ADP_LP, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_ADP_P, MEI_ME_PCH15_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_ADP_N, MEI_ME_PCH15_CFG)}, /* required last entry */ {0, } -- 2.35.1

2 years, 9 months

1
0
0 0

patch "serial: sc16is7xx: Clear RS485 bits in the shutdown" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: Clear RS485 bits in the shutdown to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 927728a34f11b5a27f4610bdb7068317d6fdc72a Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Tue, 8 Mar 2022 19:00:42 +0800 Subject: serial: sc16is7xx: Clear RS485 bits in the shutdown We tested RS485 function on an EVB which has SC16IS752, after finishing the test, we started the RS232 function test, but found the RTS is still working in the RS485 mode. That is because both startup and shutdown call port_update() to set the EFCR_REG, this will not clear the RS485 bits once the bits are set in the reconf_rs485(). To fix it, clear the RS485 bits in shutdown. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Link: https://lore.kernel.org/r/20220308110042.108451-1-hui.wang@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 683dd3be010d..91434876fcde 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1238,10 +1238,12 @@ static void sc16is7xx_shutdown(struct uart_port *port) /* Disable all interrupts */ sc16is7xx_port_write(port, SC16IS7XX_IER_REG, 0); - /* Disable TX/RX */ + /* Disable TX/RX, clear auto RS485 and RTS invert */ sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG, SC16IS7XX_EFCR_RXDISABLE_BIT | - SC16IS7XX_EFCR_TXDISABLE_BIT, + SC16IS7XX_EFCR_TXDISABLE_BIT | + SC16IS7XX_EFCR_AUTO_RS485_BIT | + SC16IS7XX_EFCR_RTS_INVERT_BIT, SC16IS7XX_EFCR_RXDISABLE_BIT | SC16IS7XX_EFCR_TXDISABLE_BIT); -- 2.35.1

2 years, 9 months

1
0
0 0

[stable:PATCH v5.4.184 00/22] arm64: Mitigate spectre style branch history side channels

by James Morse

Hi Greg, Here is the state of the current v5.4 backport. Now that the 32bit code has been merged, it doesn't conflict when KVM's shared 32bit/64bit code needs to use these constants. I've fixed the two issues that were reported against the v5.10 backport. I had a go at bringing all the pre-requisites in to add proton-pack.c to v5.4. Its currently 39 patches: https://git.gitlab.arm.com/linux-arm/linux-jm.git /bhb/alternative_backport/UNTESTED/v5.4.183 (or for web browsers: https://gitlab.arm.com/linux-arm/linux-jm/-/commits/bhb/alternative_backpor… ) I've not managed to bring b881cdce77b4 "KVM: arm64: Allocate hyp vectors statically" in, as that depends on the hypervisor's per-cpu support. Its this patch that means those 'smccc_wa' templates are needed. I estimate it would be 60 patches in total if we go this way, I don't think its a good idea: All this still has to work around 541ad0150ca4 ("arm: Remove 32bit KVM host support") and 9ed24f4b712b ("KVM: arm64: Move virt/kvm/arm to arch/arm64") being missing. I think this approach creates more problems than it solves as the files have to be in different places because of 32bit. It also creates a significantly larger testing problem: I'm not looking forward to working out how to test KVM guest migration over the variant-4 KVM ABI changes in 29e8910a566a. This version of the backport still adds the mitigation management code to cpu_errata.c, because that is where this stuff lived in v5.4. If you prefer, I can try adding proton-pack.c as a new empty file. I think this would only confuse matters as the line-numbers would never match, and there is an interaction with the spectre-v2 mitigations that live in cpu_errata.c. There is one patch not present in mainline 'KVM: arm64: Add templtes for BHB mitigation sequences'. Thanks, James Anshuman Khandual (1): arm64: Add Cortex-X2 CPU part definition James Morse (18): arm64: entry.S: Add ventry overflow sanity checks arm64: entry: Make the trampoline cleanup optional arm64: entry: Free up another register on kpti's tramp_exit path arm64: entry: Move the trampoline data page before the text page arm64: entry: Allow tramp_alias to access symbols after the 4K boundary arm64: entry: Don't assume tramp_vectors is the start of the vectors arm64: entry: Move trampoline macros out of ifdef'd section arm64: entry: Make the kpti trampoline's kpti sequence optional arm64: entry: Allow the trampoline text to occupy multiple pages arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations arm64: entry: Add vectors that have the bhb mitigation sequences arm64: entry: Add macro for reading symbol addresses from the trampoline arm64: Add percpu vectors for EL1 arm64: proton-pack: Report Spectre-BHB vulnerabilities as part of Spectre-v2 KVM: arm64: Add templates for BHB mitigation sequences arm64: Mitigate spectre style branch history side channels KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated arm64: Use the clearbhb instruction in mitigations Joey Gouly (1): arm64: add ID_AA64ISAR2_EL1 sys register Rob Herring (1): arm64: Add part number for Arm Cortex-A77 Suzuki K Poulose (1): arm64: Add Neoverse-N2, Cortex-A710 CPU part definition arch/arm/include/asm/kvm_host.h | 7 + arch/arm/include/uapi/asm/kvm.h | 6 + arch/arm64/Kconfig | 9 + arch/arm64/include/asm/assembler.h | 33 +++ arch/arm64/include/asm/cpu.h | 1 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 40 +++ arch/arm64/include/asm/cputype.h | 16 ++ arch/arm64/include/asm/fixmap.h | 6 +- arch/arm64/include/asm/kvm_host.h | 5 + arch/arm64/include/asm/kvm_mmu.h | 6 +- arch/arm64/include/asm/mmu.h | 8 +- arch/arm64/include/asm/sections.h | 5 + arch/arm64/include/asm/sysreg.h | 17 ++ arch/arm64/include/asm/vectors.h | 73 ++++++ arch/arm64/include/uapi/asm/kvm.h | 5 + arch/arm64/kernel/cpu_errata.c | 385 +++++++++++++++++++++++++++- arch/arm64/kernel/cpufeature.c | 21 ++ arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/entry.S | 213 +++++++++++---- arch/arm64/kernel/vmlinux.lds.S | 2 +- arch/arm64/kvm/hyp/hyp-entry.S | 64 +++++ arch/arm64/kvm/hyp/switch.c | 8 +- arch/arm64/kvm/sys_regs.c | 2 +- arch/arm64/mm/mmu.c | 12 +- include/linux/arm-smccc.h | 5 + virt/kvm/arm/psci.c | 34 ++- 27 files changed, 912 insertions(+), 75 deletions(-) create mode 100644 arch/arm64/include/asm/vectors.h -- 2.30.2

2 years, 9 months

3
27
0 0

[PATCH] usb: gadget: uvc: Fix crash when encoding data for usb request

by Dan Vacura

During the uvcg_video_pump() process, if an error occurs and uvcg_queue_cancel() is called, the buffer queue will be cleared out, but the current marker (queue->buf_used) of the active buffer (no longer active) is not reset. On the next iteration of uvcg_video_pump() the stale buf_used count will be used and the logic of min((unsigned int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a nbytes size, causing an invalid memory access. [80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. [80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed with status -18. ... uvcg_queue_cancel() is called and the queue is cleared out, but the marker queue->buf_used is not reset. ... [80802.262328][ T8682] Unable to handle kernel paging request at virtual address ffffffc03af9f000 ... ... [80802.263138][ T8682] Call trace: [80802.263146][ T8682] __memcpy+0x12c/0x180 [80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0 [80802.263165][ T8682] process_one_work+0x2cc/0x568 [80802.263173][ T8682] worker_thread+0x28c/0x518 [80802.263181][ T8682] kthread+0x160/0x170 [80802.263188][ T8682] ret_from_fork+0x10/0x18 [80802.263198][ T8682] Code: a8c12829 a88130cb a8c130 Signed-off-by: Dan Vacura <w36195(a)motorola.com> --- drivers/usb/gadget/function/uvc_queue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c index d852ac9e47e7..2cda982f3765 100644 --- a/drivers/usb/gadget/function/uvc_queue.c +++ b/drivers/usb/gadget/function/uvc_queue.c @@ -264,6 +264,8 @@ void uvcg_queue_cancel(struct uvc_video_queue *queue, int disconnect) buf->state = UVC_BUF_STATE_ERROR; vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_ERROR); } + queue->buf_used = 0; + /* This must be protected by the irqlock spinlock to avoid race * conditions between uvc_queue_buffer and the disconnection event that * could result in an interruptible wait in uvc_dequeue_buffer. Do not -- 2.32.0

2 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2022