November 2020 - Linux-stable-mirror

[PATCH] Revert "ath: add support for special 0x0 regulatory domain"

by Brian Norris

This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423. Users are reporting regressions in regulatory domain detection and channel availability. The problem this was trying to resolve was fixed in firmware anyway: QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042 https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc… Link: https://bbs.archlinux.org/viewtopic.php?id=254535 Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain") Cc: <stable(a)vger.kernel.org> Cc: Wen Gong <wgong(a)codeaurora.org> Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/net/wireless/ath/regd.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c index bee9110b91f3..20f4f8ea9f89 100644 --- a/drivers/net/wireless/ath/regd.c +++ b/drivers/net/wireless/ath/regd.c @@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg, /* * Some users have reported their EEPROM programmed with - * 0x8000 or 0x0 set, this is not a supported regulatory - * domain but since we have more than one user with it we - * need a solution for them. We default to 0x64, which is - * the default Atheros world regulatory domain. + * 0x8000 set, this is not a supported regulatory domain + * but since we have more than one user with it we need + * a solution for them. We default to 0x64, which is the + * default Atheros world regulatory domain. */ static void ath_regd_sanitize(struct ath_regulatory *reg) { - if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0) + if (reg->current_rd != COUNTRY_ERD_FLAG) return; printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n"); reg->current_rd = 0x64; -- 2.27.0.rc0.183.gde8f92d652-goog

2 years, 2 months

8
10
0 0

[PATCH 1/2] x86/mpparse: avoid overwriting boot_cpu_physical_apicid

by Kevin Mitchell

When booting with ACPI unavailable or disabled, get_smp_config() ends up calling MP_processor_info() for each CPU found in the MPS table. Previously, this resulted in boot_cpu_physical_apicid getting unconditionally overwritten by the apicid of whatever processor had the CPU_BOOTPROCESSOR flag. This occurred even if boot_cpu_physical_apicid had already been more reliably determined in register_lapic_address() by calling read_apic_id() from the actual boot processor. Ordinariliy, this is not a problem because the boot processor really is the one with the CPU_BOOTPROCESSOR flag. However, kexec is an exception in which the kernel may be booted from any processor regardless of the MPS table contents. In this case, boot_cpu_physical_apicid may not indicate the actual boot processor. This was particularly problematic when the second kernel was booted with NR_CPUS fewer than the number of physical processors. It's the job of generic_processor_info() to decide which CPUs to bring up in this case. That obviously must include the real boot processor which it takes care to save a slot for. It relies upon the contents of boot_cpu_physical_apicid to do this, which if incorrect, may result in the boot processor getting left out. This condition can be discovered by smp_sanity_check() and rectified by adding the boot processor to the phys_cpu_present_map with the warning "weird, boot CPU (#%d) not listed by the BIOS". However, commit 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") caused setup_local_APIC() to be called before this could happen resulting in a BUG_ON(!apic->apic_id_registered()): [ 0.655452] ------------[ cut here ]------------ [ 0.660610] Kernel BUG at setup_local_APIC+0x74/0x280 [verbose debug info unavailable] [ 0.669466] invalid opcode: 0000 [#1] SMP [ 0.673948] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.109.Ar-16509018.eostrunkkernel419 #1 [ 0.683670] Hardware name: Quanta Quanta LY6 (1LY6UZZ0FBC), BIOS 1.0.6.0-e7d6a55 11/26/2015 [ 0.693007] RIP: 0010:setup_local_APIC+0x74/0x280 [ 0.698264] Code: 80 e4 fe bf f0 00 00 00 89 c6 48 8b 05 0f 1a 8e 00 ff 50 10 e8 12 53 fd ff 48 8b 05 00 1a 8e 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05 ed 19 8e 00 41 be 00 02 00 00 ff 90 b0 00 00 00 48 [ 0.719251] RSP: 0000:ffffffff81a03e20 EFLAGS: 00010246 [ 0.725091] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 [ 0.733066] RDX: 0000000000000000 RSI: 000000000000000f RDI: 0000000000000020 [ 0.741041] RBP: ffffffff81a03e98 R08: 0000000000000002 R09: 0000000000000000 [ 0.749014] R10: ffffffff81a204e0 R11: ffffffff81b50ea7 R12: 0000000000000000 [ 0.756989] R13: ffffffff81aef920 R14: ffffffff81af60a0 R15: 0000000000000000 [ 0.764965] FS: 0000000000000000(0000) GS:ffff888036800000(0000) knlGS:0000000000000000 [ 0.774007] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.780427] CR2: ffff888035c01000 CR3: 0000000035a08000 CR4: 00000000000006b0 [ 0.788401] Call Trace: [ 0.791137] ? amd_iommu_prepare+0x15/0x2a [ 0.795717] apic_bsp_setup+0x55/0x75 [ 0.799808] apic_intr_mode_init+0x169/0x16e [ 0.804579] x86_late_time_init+0x10/0x17 [ 0.809062] start_kernel+0x37e/0x3fe [ 0.813154] x86_64_start_reservations+0x2a/0x2c [ 0.818316] x86_64_start_kernel+0x72/0x75 [ 0.822886] secondary_startup_64+0xa4/0xb0 [ 0.827564] ---[ end trace 237b64da0fd9b22e ]--- This change avoids these issues by only setting boot_cpu_physical_apicid from the MPS table if it is not already set, which can occur in the construct_default_ISA_mptable() path. Otherwise, boot_cpu_physical_apicid will already have been set in register_lapic_address() and should therefore remain untouched. Looking through all the places where boot_cpu_physical_apicid is accessed, nearly all of them assume that boot_cpu_physical_apicid should match read_apic_id() on the booting processor. The only place that might intend to use the BSP apicid listed in the MPS table is amd_numa_init(), which explicitly requires boot_cpu_physical_apicid to be the lowest apicid of all processors. Ironically, due to the early exit short circuit in early_get_smp_config(), it instead gets boot_cpu_physical_apicid = read_apic_id() rather than the MPS table BSP. The behaviour of amd_numa_init() is therefore unaffected by this change. Fixes: 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") Signed-off-by: Kevin Mitchell <kevmitch(a)arista.com> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/mpparse.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c index afac7ccce72f..6f22f09bfe11 100644 --- a/arch/x86/kernel/mpparse.c +++ b/arch/x86/kernel/mpparse.c @@ -64,7 +64,8 @@ static void __init MP_processor_info(struct mpc_cpu *m) if (m->cpuflag & CPU_BOOTPROCESSOR) { bootup_cpu = " (Bootup-CPU)"; - boot_cpu_physical_apicid = m->apicid; + if (boot_cpu_physical_apicid == -1U) + boot_cpu_physical_apicid = m->apicid; } pr_info("Processor #%d%s\n", m->apicid, bootup_cpu); -- 2.26.2

2 years, 6 months

1
1
0 0

[PATCH v3] drm/ast: Don't check new mode if CRTC is being disabled

by Thomas Zimmermann

Suspending failed because there's no mode if the CRTC is being disabled. Early-out in this case. This fixes runtime PM for ast. v3: * fixed commit message v2: * added Tested-by/Reported-by tags * added Fixes tags and CC (Sam) * improved comment Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reported-by: Cary Garrett <cogarre(a)gmail.com> Tested-by: Cary Garrett <cogarre(a)gmail.com> Fixes: b48e1b6ffd28 ("drm/ast: Add CRTC helpers for atomic modesetting") Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: <stable(a)vger.kernel.org> # v5.6+ --- drivers/gpu/drm/ast/ast_mode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 7a9f20a2fd303..0cbbb21edb4e1 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, return -EINVAL; } + if (!state->enable) + return 0; /* no mode checks if CRTC is being disabled */ + ast_state = to_ast_crtc_state(state); format = ast_state->format; -- 2.26.0

2 years, 10 months

3
3
0 0

[PATCH v2 07/17] irqchip/gic: Atomically update affinity

by Marc Zyngier

The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically. But these sequences only expend into anything meaningful if the BL_SWITCHER option is selected, which almost never happens. It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition. Drop the terminally broken code and replace it by a byte write. Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> --- drivers/irqchip/irq-gic.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 00de05abd3c3..c17fabd6741e 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -329,10 +329,8 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu) static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, bool force) { - void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); - unsigned int cpu, shift = (gic_irq(d) % 4) * 8; - u32 val, mask, bit; - unsigned long flags; + void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); + unsigned int cpu; if (!force) cpu = cpumask_any_and(mask_val, cpu_online_mask); @@ -342,13 +340,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) return -EINVAL; - gic_lock_irqsave(flags); - mask = 0xff << shift; - bit = gic_cpu_map[cpu] << shift; - val = readl_relaxed(reg) & ~mask; - writel_relaxed(val | bit, reg); - gic_unlock_irqrestore(flags); - + writeb_relaxed(gic_cpu_map[cpu], reg); irq_data_update_effective_affinity(d, cpumask_of(cpu)); return IRQ_SET_MASK_OK_DONE; -- 2.27.0

3 years, 2 months

5
11
0 0

Re: System crash on Ubuntu 18, in netlink code when using iptables / netfilter

by Florian Westphal

Yuri Lipnesh <yuri.lipnesh(a)gmail.com> wrote: > Linux system crashed > > [ 0.000000] Linux version 5.4.0-54-generic (buildd@lcy01-amd64-008) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #60~18.04.1-Ubuntu SMP Fri Nov 6 17:25:16 UTC 2020 (Ubuntu 5.4.0-54.60~18.04.1-generic 5.4.65) > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-54-generic root=UUID=11885fd3-b840-4c9b-a500-532c73ac952a ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet crashkernel=512M-:192M > > … > [ 156.321147] TCP: eth0: Driver has suspect GRO implementation, TCP performance may be compromised. > [ 177.519159] general protection fault: 0000 [#1] SMP PTI > [ 177.519737] CPU: 5 PID: 18484 Comm: worker-1 Kdump: loaded Not tainted 5.4.0-54-generic #60~18.04.1-Ubuntu > [ 177.519742] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 > [ 177.519814] RIP: 0010:dev_hard_start_xmit+0x38/0x200 > [ 177.519827] Code: 55 41 54 53 48 83 ec 20 48 85 ff 48 89 55 c8 48 89 4d b8 0f 84 c1 01 00 00 48 8d 86 90 00 00 00 48 89 fb 49 89 f4 48 89 45 c0 <4c> 8b 2b 48 c7 c0 d0 f2 04 8f 48 c7 03 00 00 00 00 48 8b 00 4d 85 > [ 177.519829] RSP: 0018:ffffbc6d0609b5e8 EFLAGS: 00010286 > [ 177.519833] RAX: 0000000000000000 RBX: dead000000000100 RCX: ffff95cf4bcfe800 > [ 177.519835] RDX: 0000000000000000 RSI: ffff95cf4bcfe800 RDI: 0000000000000286 > [ 177.519837] RBP: ffffbc6d0609b630 R08: ffff95cf6a190ec8 R09: ffff95cf4a2f7438 > [ 177.519839] R10: ffffbc6d0609b6d0 R11: ffff95cf49d4d180 R12: ffff95cf51a5f000 > [ 177.519841] R13: dead000000000100 R14: 000000000000009c R15: ffff95d02996b400 > [ 177.519844] FS: 00007ff394cdfb20(0000) GS:ffff95d035d40000(0000) knlGS:0000000000000000 > [ 177.519846] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 177.519848] CR2: 00007fb4a9c2d000 CR3: 00000001049fa004 CR4: 00000000003606e0 > [ 177.519908] Call Trace: > [ 177.519917] __dev_queue_xmit+0x719/0x920 > [ 177.519930] ? ctnetlink_conntrack_event+0x8c/0x5e0 [nf_conntrack_netlink] Can you reproduce this on 5.7 or later, or with following patches backported to 5.4.y? dd3cc111f2e3220ddc9c4ab17f13dc97759b5163 119e52e664c57d5f7c0174dc2b3a296b1e40591d af370ab36fcd19f04e3408c402608e7e56e6f188 28f715b9e6dd7cbf07c2aea913fea7c87a56a3b5 The series fixed nfqueue reference counting.

3 years, 2 months

2
3
0 0

Re: [PATCH v2 11/12] mac80211: drop data frames without key on encrypted links

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.5.11, v5.4.27, v4.19.112, v4.14.174, v4.9.217, v4.4.217. v5.5.11: Build OK! v5.4.27: Build OK! v4.19.112: Failed to apply! Possible dependencies: 03512ceb60ae ("ieee80211: remove redundant leading zeroes") 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support") 0eeb2b674f05 ("mac80211: add an option for station management TXQ") 1c9559734eca ("mac80211: remove unnecessary key condition") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear text leak") 77f7ffdc335d ("mac80211: minstrel_ht: add flag to indicate missing/inaccurate tx A-MPDU length") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 80aaa9c16415 ("mac80211: Add he_capa debugfs entry") 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support") add7453ad62f ("wireless: align to draft 11ax D3.0") adf8ed01e4fd ("mac80211: add an optional TXQ for other PS-buffered frames") caf56338c22f ("mac80211: indicate support for multiple BSSID") daa5b83513a7 ("mac80211: update HE operation fields to D3.0") v4.14.174: Failed to apply! Possible dependencies: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") 1c73acf58bd6 ("iwlwifi: acpi: move ACPI method definitions to acpi.h") 28e9c00fe1f0 ("iwlwifi: remove upper case letters in sku_capa_band_*_enable") 4ae80f6c8d86 ("iwlwifi: support api ver2 of NVM_GET_INFO resp") 4b82455ca51e ("iwlwifi: use flags to denote modifiers for the channel maps") 4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c") 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 813df5cef3bb ("iwlwifi: acpi: add common code to read from ACPI") 8a6171a7b601 ("iwlwifi: fw: add FW APIs for HE") 9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common files") 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") e7a3b8d87910 ("iwlwifi: acpi: move ACPI-related definitions to acpi.h") v4.9.217: Failed to apply! Possible dependencies: 01796ff2fa6e ("iwlwifi: mvm: always free inactive queue when moving ownership") 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 1ea423b0e047 ("iwlwifi: remove unnecessary dev_cmd_headroom parameter") 310181ec34e2 ("iwlwifi: move to TVQM mode") 5594d80e9bf4 ("iwlwifi: support two phys for a000 devices") 623e7766be90 ("iwlwifi: pcie: introduce split point to a000 devices") 65e254821cee ("iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS") 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") 727c02dfb848 ("iwlwifi: pcie: cleanup rfkill checks") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 8236f7db2724 ("iwlwifi: mvm: assign cab queue to the correct station") 87d0e1af9db3 ("iwlwifi: mvm: separate queue mapping from queue enablement") bb49701b41de ("iwlwifi: mvm: support a000 SCD queue configuration") cf90da352a32 ("iwlwifi: mvm: use mvm_disable_queue instead of sharing logic") d172a5eff629 ("iwlwifi: reorganize firmware API") df88c08d5c7e ("iwlwifi: mvm: release static queues on bcast release") eda50cde58de ("iwlwifi: pcie: add context information support") v4.4.217: Failed to apply! Possible dependencies: 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 13555e8ba2f4 ("iwlwifi: mvm: add 9000-series RX API") 1a616dd2f171 ("iwlwifi: dump prph registers in a common place for all transports") 1e0bbebaae66 ("mac80211: enable starting BA session with custom timeout") 2f89a5d7d377 ("iwlwifi: mvm: move fw-dbg code to separate file") 39bdb17ebb5b ("iwlwifi: update host command messages to new format") 41837ca962ec ("iwlwifi: pcie: allow to pretend to have Tx CSUM for debug") 4707fde5cdef ("iwlwifi: mvm: use build-time assertion for fw trigger ID") 5b88792cd850 ("iwlwifi: move to wide ID for all commands") 6c4fbcbc1c95 ("iwlwifi: add support for 12K Receive Buffers") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 92fe83430b89 ("iwlwifi: uninline iwl_trans_send_cmd") d172a5eff629 ("iwlwifi: reorganize firmware API") dcbb4746286a ("iwlwifi: trans: support a callback for ASYNC commands") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

3 years, 3 months

5
8
0 0

Re: [PATCH v3] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

by Vincent Guittot

On Thu, 19 Nov 2020 at 01:36, Tao Zhou <t1zhou(a)163.com> wrote: > > On Thu, Nov 19, 2020 at 07:50:15AM +0800, Tao Zhou wrote: > > On Wed, Nov 18, 2020 at 07:56:38PM -0300, Guilherme G. Piccoli wrote: > > > Hi Vincent (and all CCed), I'm sorry to ping about such "old" patch, but > > > we experienced a similar condition to what this patch addresses; it's an > > > older kernel (4.15.x) but when suggesting the users to move to an > > > updated 5.4.x kernel, we noticed that this patch is not there, although > > > similar ones are (like [0] and [1]). > > > > > > So, I'd like to ask if there's any particular reason to not backport > > > this fix to stable kernels, specially the longterm 5.4. The main reason > > > behind the question is that the code is very complex for non-experienced > > > scheduler developers, and I'm afraid in suggesting such backport to 5.4 > > > and introduce complex-to-debug issues. > > > > > > Let me know your thoughts Vincent (and all CCed), thanks in advance. > > > Cheers, > > > > > > > > > Guilherme > > > > > > > > > P.S. For those that deleted this thread from the email client, here's a > > > link: > > > https://lore.kernel.org/lkml/20200513135528.4742-1-vincent.guittot@linaro.o… > > > > > > > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > > > > > [1] > > > https://lore.kernel.org/lkml/20200506141821.GA9773@lorien.usersys.redhat.co… > > > <- great thread BTW! > > > > 'sched/fair: Fix unthrottle_cfs_rq() for leaf_cfs_rq list" failed to apply to > > 5.4-stable tree' > > > > You could check above. But I do not have the link about this. Can't search it > > on LKML web: https://lore.kernel.org/lkml/ > > > > BTW: 'ouwen210(a)hotmail.com' and 'zohooouoto(a)zoho.com.cn' all is myself. > > > > Sorry for the confusing.. > > > > Thanks. > > Sorry again. I forget something. It is in the stable. > > Here it is: > > https://lore.kernel.org/stable/159041776924279@kroah.com/ I think it has never been applied to stable. As you mentioned, the backport has been sent : https://lore.kernel.org/stable/20200525172709.GB7427@vingu-book/ I received another emailed in September and pointed out to the backport : https://www.spinics.net/lists/stable/msg410445.html >

3 years, 5 months

4
5
0 0

[PATCH 1/2] KVM: SVM: avoid infinite loop on NPF from bad address

by Paolo Bonzini

When a nested page fault is taken from an address that does not have a memslot associated to it, kvm_mmu_do_page_fault returns RET_PF_EMULATE (via mmu_set_spte) and kvm_mmu_page_fault then invokes svm_need_emulation_on_page_fault. The default answer there is to return false, but in this case this just causes the page fault to be retried ad libitum. Since this is not a fast path, and the only other case where it is taken is an erratum, just stick a kvm_vcpu_gfn_to_memslot check in there to detect the common case where the erratum is not happening. This fixes an infinite loop in the new set_memory_region_test. Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)") Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/svm/svm.c | 7 +++++++ virt/kvm/kvm_main.c | 1 + 2 files changed, 8 insertions(+) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index a91e397d6750..c86f7278509b 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3837,6 +3837,13 @@ static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu) bool smap = cr4 & X86_CR4_SMAP; bool is_user = svm_get_cpl(vcpu) == 3; + /* + * If RIP is invalid, go ahead with emulation which will cause an + * internal error exit. + */ + if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT)) + return true; + /* * Detect and workaround Errata 1096 Fam_17h_00_0Fh. * diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e2f60e313c87..e7436d054305 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1602,6 +1602,7 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn { return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn); } +EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot); bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn) { -- 2.18.2

3 years, 5 months

4
7
0 0

[PATCH] ARM: dts: at91: sama5d4: fix pinctrl muxing

by Ludovic Desroches

Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It allows to use SCK0, SCK1 and SPI0_NPCS2 signals. Signed-off-by: Ludovic Desroches <ludovic.desroches(a)microchip.com> Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD") Cc: stable(a)vger.kernel.org --- arch/arm/boot/dts/sama5d4.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi index 6ab27a7b388d..a4cef07c38cb 100644 --- a/arch/arm/boot/dts/sama5d4.dtsi +++ b/arch/arm/boot/dts/sama5d4.dtsi @@ -914,7 +914,7 @@ /* A B C */ 0xffffffff 0x3ffcfe7c 0x1c010101 /* pioA */ 0x7fffffff 0xfffccc3a 0x3f00cc3a /* pioB */ 0xffffffff 0x3ff83fff 0xff00ffff /* pioC */ - 0x0003ff00 0x8002a800 0x00000000 /* pioD */ + 0xb003ff00 0x8002a800 0x00000000 /* pioD */ 0xffffffff 0x7fffffff 0x76fff1bf /* pioE */ >; -- 2.24.0.rc0

3 years, 5 months

3
2
0 0

[PATCH 00/30 for 5.4] Backport unencrypted non-blocking DMA allocations

by Peter Gonda

Currently SEV enabled guests hit might_sleep() warnings when a driver (nvme in this case) allocates through the DMA API in a non-blockable context. Making these unencrypted non-blocking DMA allocations come from the coherent pools prevents this BUG. BUG: sleeping function called from invalid context at mm/vmalloc.c:1710 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3383, name: fio 2 locks held by fio/3383: #0: ffff93b6a8568348 (&sb->s_type->i_mutex_key#16){+.+.}, at: ext4_file_write_iter+0xa2/0x5d0 #1: ffffffffa52a61a0 (rcu_read_lock){....}, at: hctx_lock+0x1a/0xe0 CPU: 0 PID: 3383 Comm: fio Tainted: G W 5.5.10 #14 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0x98/0xd5 ___might_sleep+0x175/0x260 __might_sleep+0x4a/0x80 _vm_unmap_aliases+0x45/0x250 vm_unmap_aliases+0x19/0x20 __set_memory_enc_dec+0xa4/0x130 set_memory_decrypted+0x10/0x20 dma_direct_alloc_pages+0x148/0x150 dma_direct_alloc+0xe/0x10 dma_alloc_attrs+0x86/0xc0 dma_pool_alloc+0x16f/0x2b0 nvme_queue_rq+0x878/0xc30 [nvme] __blk_mq_try_issue_directly+0x135/0x200 blk_mq_request_issue_directly+0x4f/0x80 blk_mq_try_issue_list_directly+0x46/0xb0 blk_mq_sched_insert_requests+0x19b/0x2b0 blk_mq_flush_plug_list+0x22f/0x3b0 blk_flush_plug_list+0xd1/0x100 blk_finish_plug+0x2c/0x40 iomap_dio_rw+0x427/0x490 ext4_file_write_iter+0x181/0x5d0 aio_write+0x109/0x1b0 io_submit_one+0x7d0/0xfa0 __x64_sys_io_submit+0xa2/0x280 do_syscall_64+0x5f/0x250 entry_SYSCALL_64_after_hwframe+0x49/0xbe Christoph Hellwig (9): dma-direct: remove __dma_direct_free_pages dma-direct: remove the dma_handle argument to __dma_direct_alloc_pages dma-direct: provide mmap and get_sgtable method overrides dma-mapping: merge the generic remapping helpers into dma-direct dma-direct: consolidate the error handling in dma_direct_alloc_pages xtensa: use the generic uncached segment support dma-direct: make uncached_kernel_address more general dma-mapping: DMA_COHERENT_POOL should select GENERIC_ALLOCATOR dma-pool: fix coherent pool allocations for IOMMU mappings David Rientjes (13): dma-remap: separate DMA atomic pools from direct remap code dma-pool: add additional coherent pools to map to gfp mask dma-pool: dynamically expanding atomic pools dma-direct: atomic allocations must come from atomic coherent pools dma-pool: add pool sizes to debugfs x86/mm: unencrypted non-blocking DMA allocations use coherent pools dma-pool: scale the default DMA coherent pool size with memory capacity dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL dma-direct: always align allocation size in dma_direct_alloc_pages() dma-direct: re-encrypt memory if dma_direct_alloc_pages() fails dma-direct: check return value when encrypting or decrypting memory dma-direct: add missing set_memory_decrypted() for coherent mapping dma-mapping: warn when coherent pool is depleted Geert Uytterhoeven (1): dma-pool: fix too large DMA pools on medium memory size systems Huang Shijie (1): lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr Nicolas Saenz Julienne (6): dma-direct: provide function to check physical memory area validity dma-pool: get rid of dma_in_atomic_pool() dma-pool: introduce dma_guess_pool() dma-pool: make sure atomic pool suits device dma-pool: do not allocate pool memory from CMA dma/direct: turn ARCH_ZONE_DMA_BITS into a variable Documentation/core-api/genalloc.rst | 2 +- arch/Kconfig | 8 +- arch/arc/Kconfig | 1 - arch/arm/Kconfig | 1 - arch/arm/mm/dma-mapping.c | 8 +- arch/arm64/Kconfig | 1 - arch/arm64/mm/init.c | 9 +- arch/ia64/Kconfig | 2 +- arch/ia64/kernel/dma-mapping.c | 6 - arch/microblaze/Kconfig | 3 +- arch/microblaze/mm/consistent.c | 2 +- arch/mips/Kconfig | 7 +- arch/mips/mm/dma-noncoherent.c | 8 +- arch/nios2/Kconfig | 3 +- arch/nios2/mm/dma-mapping.c | 2 +- arch/powerpc/include/asm/page.h | 9 - arch/powerpc/mm/mem.c | 20 +- arch/powerpc/platforms/Kconfig.cputype | 1 - arch/s390/include/asm/page.h | 2 - arch/s390/mm/init.c | 1 + arch/x86/Kconfig | 1 + arch/xtensa/Kconfig | 6 +- arch/xtensa/include/asm/platform.h | 27 --- arch/xtensa/kernel/Makefile | 3 +- arch/xtensa/kernel/pci-dma.c | 121 ++--------- drivers/iommu/dma-iommu.c | 5 +- drivers/misc/sram-exec.c | 2 +- include/linux/dma-direct.h | 12 +- include/linux/dma-mapping.h | 7 +- include/linux/dma-noncoherent.h | 4 +- include/linux/genalloc.h | 2 +- kernel/dma/Kconfig | 20 +- kernel/dma/Makefile | 1 + kernel/dma/direct.c | 224 ++++++++++++++++---- kernel/dma/mapping.c | 45 +---- kernel/dma/pool.c | 270 +++++++++++++++++++++++++ kernel/dma/remap.c | 176 +--------------- lib/genalloc.c | 5 +- 38 files changed, 564 insertions(+), 463 deletions(-) create mode 100644 kernel/dma/pool.c -- 2.28.0.618.gf4bc123cb7-goog

3 years, 6 months

3
38
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2020