October 2023 - Linux-stable-mirror

[PATCH v3] acpi/processor: sanitize _OSC/_PDC capabilities for Xen dom0

by Jason Andryuk

From: Roger Pau Monne <roger.pau(a)citrix.com> The Processor capability bits notify ACPI of the OS capabilities, and so ACPI can adjust the return of other Processor methods taking the OS capabilities into account. When Linux is running as a Xen dom0, the hypervisor is the entity in charge of processor power management, and hence Xen needs to make sure the capabilities reported by _OSC/_PDC match the capabilities of the driver in Xen. Introduce a small helper to sanitize the buffer when running as Xen dom0. When Xen supports HWP, this serves as the equivalent of commit a21211672c9a ("ACPI / processor: Request native thermal interrupt handling via _OSC") to avoid SMM crashes. Xen will set bit ACPI_PROC_CAP_COLLAB_PROC_PERF (bit 12) in the capability bits and the _OSC/_PDC call will apply it. [ jandryuk: Mention Xen HWP's need. Support _OSC & _PDC ] Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com> Cc: stable(a)vger.kernel.org Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com> --- v3: Move xen_sanitize_pdc() call to arch_acpi_set_proc_cap_bits() to cover _OSC and _PDC. drivers/xen/pcpu.c is CONFIG_DOM0 && CONFIG_X86 v2: Move local variables in acpi_processor_eval_pdc() to reuse in both conditions. --- arch/x86/include/asm/acpi.h | 13 +++++++++++++ arch/x86/include/asm/xen/hypervisor.h | 9 +++++++++ drivers/xen/pcpu.c | 21 +++++++++++++++++++++ 3 files changed, 43 insertions(+) diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index c8a7fc23f63c..cc8d1669d6e8 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -16,6 +16,9 @@ #include <asm/x86_init.h> #include <asm/cpufeature.h> #include <asm/irq_vectors.h> +#include <asm/xen/hypervisor.h> + +#include <xen/xen.h> #ifdef CONFIG_ACPI_APEI # include <asm/pgtable_types.h> @@ -127,6 +130,16 @@ static inline void arch_acpi_set_proc_cap_bits(u32 *cap) if (!cpu_has(c, X86_FEATURE_MWAIT) || boot_option_idle_override == IDLE_NOMWAIT) *cap &= ~(ACPI_PROC_CAP_C_C1_FFH | ACPI_PROC_CAP_C_C2C3_FFH); + + if (xen_initial_domain()) { + /* + * When Linux is running as Xen dom0, the hypervisor is the + * entity in charge of the processor power management, and so + * Xen needs to check the OS capabilities reported in the _PDC + * buffer matches what the hypervisor driver supports. + */ + xen_sanitize_pdc(cap); + } } static inline bool acpi_has_cpu_in_madt(void) diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h index 7048dfacc04b..c6c2f174fa30 100644 --- a/arch/x86/include/asm/xen/hypervisor.h +++ b/arch/x86/include/asm/xen/hypervisor.h @@ -100,4 +100,13 @@ static inline void leave_lazy(enum xen_lazy_mode mode) enum xen_lazy_mode xen_get_lazy_mode(void); +#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) +void xen_sanitize_pdc(uint32_t *buf); +#else +static inline void xen_sanitize_pdc(uint32_t *buf) +{ + BUG(); +} +#endif + #endif /* _ASM_X86_XEN_HYPERVISOR_H */ diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c index b3e3d1bb37f3..859bb6027105 100644 --- a/drivers/xen/pcpu.c +++ b/drivers/xen/pcpu.c @@ -47,6 +47,9 @@ #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> +#ifdef CONFIG_ACPI +#include <acpi/processor.h> +#endif /* * @cpu_id: Xen physical cpu logic number @@ -400,4 +403,22 @@ bool __init xen_processor_present(uint32_t acpi_id) return online; } + +void xen_sanitize_pdc(uint32_t *cap) +{ + struct xen_platform_op op = { + .cmd = XENPF_set_processor_pminfo, + .u.set_pminfo.id = -1, + .u.set_pminfo.type = XEN_PM_PDC, + }; + u32 buf[3] = { ACPI_PDC_REVISION_ID, 1, *cap }; + int ret; + + set_xen_guest_handle(op.u.set_pminfo.pdc, buf); + ret = HYPERVISOR_platform_op(&op); + if (ret) + pr_info("sanitize of _PDC buffer bits from Xen failed: %d\n", + ret); + *cap = buf[2]; +} #endif -- 2.41.0

1 year, 4 months

2
2
0 0

[PATCH 0/3] net: add sysctl accept_ra_min_lft

by Patrick Rohr

Hi Greg & Sasha, I am following up on https://lore.kernel.org/stable/20230925211034.905320-1-prohr@google.com/ with cherry-picks for 5.15.135 and 5.10.198. Note that they also cleanly apply to 5.4.258, 4.19.296, and 4.14.327. I have run our test suite against all of these branches with the changes applied -- all passed. I have skipped the UAPI portions in the first two patches as these are not actually necessary to get the sysctls working. The rest of the patches applied cleanly. Thanks! -Patrick Patrick Rohr (3): net: add sysctl accept_ra_min_rtr_lft net: change accept_ra_min_rtr_lft to affect all RA lifetimes net: release reference to inet6_dev pointer Documentation/networking/ip-sysctl.rst | 8 ++++++++ include/linux/ipv6.h | 1 + net/ipv6/addrconf.c | 12 ++++++++++++ net/ipv6/ndisc.c | 13 +++++++++++-- 4 files changed, 32 insertions(+), 2 deletions(-) -- 2.42.0.655.g421f12c284-goog

1 year, 4 months

2
5
0 0

[PATCH 6.1 0/6] 6.1.58-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.58 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 14 Oct 2023 18:00:23 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.58-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.1.58-rc1 Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> lib/test_meminit: fix off-by-one error in test_pages() Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "NFS: Fix error handling for O_DIRECT write scheduling" Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "NFS: Fix O_DIRECT locking issues" Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "NFS: More O_DIRECT accounting fixes for error paths" Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "NFS: Use the correct commit info in nfs_join_page_group()" Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "NFS: More fixes for nfs_direct_write_reschedule_io()" ------------- Diffstat: Makefile | 4 +- fs/nfs/direct.c | 134 +++++++++++++++-------------------------------- fs/nfs/write.c | 23 ++++---- include/linux/nfs_page.h | 4 +- lib/test_meminit.c | 2 +- 5 files changed, 56 insertions(+), 111 deletions(-)

1 year, 4 months

9
14
0 0

Re: [PATCH 1/3] wifi: mt76: mt7915: remove VHT160 capability on MT7915

by Oleksandr Natalenko

Hello Felix. On středa 26. července 2023 11:17:02 CEST Felix Fietkau wrote: > The IEEE80211_VHT_CAP_EXT_NSS_BW value already indicates support for half-NSS > 160 MHz support, so it is wrong to also advertise full 160 MHz support. > > Fixes: c2f73eacee3b ("wifi: mt76: mt7915: add back 160MHz channel width support for MT7915") > Signed-off-by: Felix Fietkau <nbd(a)nbd.name> > --- > drivers/net/wireless/mediatek/mt76/mt7915/init.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/init.c b/drivers/net/wireless/mediatek/mt76/mt7915/init.c > index ee976657bfc3..78552f10b377 100644 > --- a/drivers/net/wireless/mediatek/mt76/mt7915/init.c > +++ b/drivers/net/wireless/mediatek/mt76/mt7915/init.c > @@ -414,7 +414,6 @@ mt7915_init_wiphy(struct mt7915_phy *phy) > if (!dev->dbdc_support) > vht_cap->cap |= > IEEE80211_VHT_CAP_SHORT_GI_160 | > - IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ | > FIELD_PREP(IEEE80211_VHT_CAP_EXT_NSS_BW_MASK, 1); > } else { > vht_cap->cap |= > For some reason this got backported into the stable kernel: ``` $ git log --oneline v6.5.2..v6.5.4 -- drivers/net/wireless/mediatek/mt76/mt7915/ c43017fbebcc3 wifi: mt76: mt7915: fix power-limits while chan_switch edb1afe042c74 wifi: mt76: mt7915: fix tlv length of mt7915_mcu_get_chan_mib_info 9ec0dec0baea3 wifi: mt76: mt7915: remove VHT160 capability on MT7915 0e61f73e6ebc0 wifi: mt76: mt7915: fix capabilities in non-AP mode 6bce28ce28390 wifi: mt76: mt7915: fix command timeout in AP stop period 7af917d4864c6 wifi: mt76: mt7915: rework tx bytes counting when WED is active feae00c6468ce wifi: mt76: mt7915: rework tx packets counting when WED is active 70bbcc4ad6544 wifi: mt76: mt7915: fix background radar event being blocked ``` and this broke my mt7915-based AP. However, if I remove `[VT160]` capability from the hostapd config, things go back to normal. It does seem that 160 MHz still works even. Is this expected? Please check. Thanks. -- Oleksandr Natalenko (post-factum)

1 year, 4 months

6
7
0 0

[PATCH 3/3] nvmem: imx: correct nregs for i.MX6ULL

by srinivas.kandagatla＠linaro.org

From: Peng Fan <peng.fan(a)nxp.com> The nregs for i.MX6ULL should be 80 per fuse map, correct it. Fixes: ffbc34bf0e9c ("nvmem: imx-ocotp: Implement i.MX6ULL/ULZ support") Cc: <Stable(a)vger.kernel.org> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/imx-ocotp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 921afe114a2c..e8b6f194925d 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -519,7 +519,7 @@ static const struct ocotp_params imx6ul_params = { }; static const struct ocotp_params imx6ull_params = { - .nregs = 64, + .nregs = 80, .bank_address_words = 0, .set_timing = imx_ocotp_set_imx6_timing, .ctrl = IMX_OCOTP_BM_CTRL_DEFAULT, -- 2.25.1

1 year, 4 months

1
0
0 0

[PATCH 2/3] nvmem: imx: correct nregs for i.MX6UL

by srinivas.kandagatla＠linaro.org

From: Peng Fan <peng.fan(a)nxp.com> The nregs for i.MX6UL should be 144 per fuse map, correct it. Fixes: 4aa2b4802046 ("nvmem: octop: Add support for imx6ul") Cc: <Stable(a)vger.kernel.org> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/imx-ocotp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 7302f25b14a1..921afe114a2c 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -512,7 +512,7 @@ static const struct ocotp_params imx6sx_params = { }; static const struct ocotp_params imx6ul_params = { - .nregs = 128, + .nregs = 144, .bank_address_words = 0, .set_timing = imx_ocotp_set_imx6_timing, .ctrl = IMX_OCOTP_BM_CTRL_DEFAULT, -- 2.25.1

1 year, 4 months

1
0
0 0

[PATCH 1/3] nvmem: imx: correct nregs for i.MX6SLL

by srinivas.kandagatla＠linaro.org

From: Peng Fan <peng.fan(a)nxp.com> The nregs for i.MX6SLL should be 80 per fuse map, correct it. Fixes: 6da27821a6f5 ("nvmem: imx-ocotp: add support for imx6sll") Cc: <Stable(a)vger.kernel.org> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/imx-ocotp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index a223d9537f22..7302f25b14a1 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -498,7 +498,7 @@ static const struct ocotp_params imx6sl_params = { }; static const struct ocotp_params imx6sll_params = { - .nregs = 128, + .nregs = 80, .bank_address_words = 0, .set_timing = imx_ocotp_set_imx6_timing, .ctrl = IMX_OCOTP_BM_CTRL_DEFAULT, -- 2.25.1

1 year, 4 months

1
0
0 0

[PATCH v2 0/3] nvmem: imx: correct nregs for i.MX6UL/ULL/SLL

by Peng Fan (OSS)

The current code does not include the register space hole, after check the fuse map of the three SoCs, update the nregs to fix the issue. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- Changes in v2: - Cc stable kernel list in patch - Link to v1: https://lore.kernel.org/r/20231008-nvmem-imx-v1-0-cabeb18ab676@nxp.com --- Peng Fan (3): nvmem: imx: correct nregs for i.MX6SLL nvmem: imx: correct nregs for i.MX6UL nvmem: imx: correct nregs for i.MX6ULL drivers/nvmem/imx-ocotp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- base-commit: 0f0fe5040de5e5fd9b040672e37725b046e312f0 change-id: 20231008-nvmem-imx-1af696badaf5 Best regards, -- Peng Fan <peng.fan(a)nxp.com>

1 year, 4 months

2
4
0 0

[PATCH v1] svcrdma: Drop connection after an RDMA Read error

by Chuck Lever

From: Chuck Lever <chuck.lever(a)oracle.com> When an RPC Call message cannot be pulled from the client, that is a message loss, by definition. Close the connection to trigger the client to resend. Cc: <stable(a)vger.kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c index 85c8bcaebb80..3b05f90a3e50 100644 --- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c @@ -852,7 +852,8 @@ int svc_rdma_recvfrom(struct svc_rqst *rqstp) if (ret == -EINVAL) svc_rdma_send_error(rdma_xprt, ctxt, ret); svc_rdma_recv_ctxt_put(rdma_xprt, ctxt); - return ret; + svc_xprt_deferred_close(xprt); + return -ENOTCONN; out_backchannel: svc_rdma_handle_bc_reply(rqstp, ctxt);

1 year, 4 months

3
2
0 0

[PATCH 10/18] rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects

by Frederic Weisbecker

From: Catalin Marinas <catalin.marinas(a)arm.com> Since the actual slab freeing is deferred when calling kvfree_rcu(), so is the kmemleak_free() callback informing kmemleak of the object deletion. From the perspective of the kvfree_rcu() caller, the object is freed and it may remove any references to it. Since kmemleak does not scan RCU internal data storing the pointer, it will report such objects as leaks during the grace period. Tell kmemleak to ignore such objects on the kvfree_call_rcu() path. Note that the tiny RCU implementation does not have such issue since the objects can be tracked from the rcu_ctrlblk structure. Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://lore.kernel.org/all/F903A825-F05F-4B77-A2B5-7356282FBA2C@apple.com/ Cc: <stable(a)vger.kernel.org> Tested-by: Christoph Paasch <cpaasch(a)apple.com> Reviewed-by: Paul E. McKenney <paulmck(a)kernel.org> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org> --- kernel/rcu/tree.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index a83ecab77917..4dd7df30df31 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -31,6 +31,7 @@ #include <linux/bitops.h> #include <linux/export.h> #include <linux/completion.h> +#include <linux/kmemleak.h> #include <linux/moduleparam.h> #include <linux/panic.h> #include <linux/panic_notifier.h> @@ -3389,6 +3390,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr) success = true; } + /* + * The kvfree_rcu() caller considers the pointer freed at this point + * and likely removes any references to it. Since the actual slab + * freeing (and kmemleak_free()) is deferred, tell kmemleak to ignore + * this object (no scanning or false positives reporting). + */ + kmemleak_ignore(ptr); + // Set timer to drain after KFREE_DRAIN_JIFFIES. if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING) schedule_delayed_monitor_work(krcp); -- 2.34.1

1 year, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023