September 2024 - Linux-stable-mirror

[PATCH 6.1 0/2] io_uring/io-wq: respect cgroup cpusets

by Felix Moessbauer

Hi, as discussed in [1], this is a manual backport of the remaining two patches to let the io worker threads respect the affinites defined by the cgroup of the process. In 6.1 one worker is created per NUMA node, while in da64d6db3bd3 ("io_uring: One wqe per wq") this is changed to only have a single worker. As this patch is pretty invasive, Jens and me agreed to not backport it. Instead we now limit the workers cpuset to the cpus that are in the intersection between what the cgroup allows and what the NUMA node has. This leaves the question what to do in case the intersection is empty: To be backwarts compatible, we allow this case, but restrict the cpumask of the poller to the cpuset defined by the cgroup. We further believe this is a reasonable decision, as da64d6db3bd3 drops the NUMA awareness anyways. [1] https://lore.kernel.org/lkml/ec01745a-b102-4f6e-abc9-abd636d36319@kernel.dk Best regards, Felix Moessbauer Siemens AG Felix Moessbauer (2): io_uring/io-wq: do not allow pinning outside of cpuset io_uring/io-wq: inherit cpuset of cgroup in io worker io_uring/io-wq.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) -- 2.39.2

1 year, 2 months

5
7
0 0

[PATCH 2/2] clk: samsung: Fixes PLL locktime for PLL142XX used on FSD platfom

by Varada Pavani

Add PLL locktime for PLL142XX controller. Fixes: 4f346005aaed ("clk: samsung: fsd: Add initial clock support") Cc: stable(a)vger.kernel.org Signed-off-by: Varada Pavani <v.pavani(a)samsung.com> --- drivers/clk/samsung/clk-pll.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c index 4be879ab917e..d4c5ae20de4f 100644 --- a/drivers/clk/samsung/clk-pll.c +++ b/drivers/clk/samsung/clk-pll.c @@ -206,6 +206,7 @@ static const struct clk_ops samsung_pll3000_clk_ops = { */ /* Maximum lock time can be 270 * PDIV cycles */ #define PLL35XX_LOCK_FACTOR (270) +#define PLL142XX_LOCK_FACTOR (150) #define PLL35XX_MDIV_MASK (0x3FF) #define PLL35XX_PDIV_MASK (0x3F) @@ -272,7 +273,11 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate, } /* Set PLL lock time. */ - writel_relaxed(rate->pdiv * PLL35XX_LOCK_FACTOR, + if (pll->type == pll_142xx) + writel_relaxed(rate->pdiv * PLL142XX_LOCK_FACTOR, + pll->lock_reg); + else + writel_relaxed(rate->pdiv * PLL35XX_LOCK_FACTOR, pll->lock_reg); /* Change PLL PMS values */ -- 2.17.1

1 year, 2 months

2
2
0 0

[PATCH 2/2] clk: samsung: Fixes PLL locktime for PLL142XX used on FSD platfom

by Varada Pavani

Add PLL locktime for PLL142XX controller. Fixes: 4f346005aaed ("clk: samsung: fsd: Add initial clock support") Cc: stable(a)vger.kernel.org Signed-off-by: Varada Pavani <v.pavani(a)samsung.com> --- drivers/clk/samsung/clk-pll.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c index 4be879ab917e..d4c5ae20de4f 100644 --- a/drivers/clk/samsung/clk-pll.c +++ b/drivers/clk/samsung/clk-pll.c @@ -206,6 +206,7 @@ static const struct clk_ops samsung_pll3000_clk_ops = { */ /* Maximum lock time can be 270 * PDIV cycles */ #define PLL35XX_LOCK_FACTOR (270) +#define PLL142XX_LOCK_FACTOR (150) #define PLL35XX_MDIV_MASK (0x3FF) #define PLL35XX_PDIV_MASK (0x3F) @@ -272,7 +273,11 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate, } /* Set PLL lock time. */ - writel_relaxed(rate->pdiv * PLL35XX_LOCK_FACTOR, + if (pll->type == pll_142xx) + writel_relaxed(rate->pdiv * PLL142XX_LOCK_FACTOR, + pll->lock_reg); + else + writel_relaxed(rate->pdiv * PLL35XX_LOCK_FACTOR, pll->lock_reg); /* Change PLL PMS values */ -- 2.17.1

1 year, 2 months

2
2
0 0

AMD drm patch workflow is broken for stable trees

by Greg KH

Hi all, As some of you have noticed, there's a TON of failure messages being sent out for AMD gpu driver commits that are tagged for stable backports. In short, you all are doing something really wrong with how you are tagging these. Please fix it up to NOT have duplicates in multiple branches that end up in Linus's tree at different times. Or if you MUST do that, then give us a chance to figure out that it IS a duplicate. As-is, it's not working at all, and I think I need to just drop all patches for this driver that are tagged for stable going forward and rely on you all to provide a proper set of backported fixes when you say they are needed. Again, what you are doing today is NOT ok and is broken. Please fix. greg k-h

1 year, 2 months

3
11
0 0

[PATCH net 02/10] ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()

by Tony Nguyen

From: Gui-Dong Han <hanguidong02(a)outlook.com> This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)outlook.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> --- drivers/net/ethernet/intel/ice/ice_dpll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c index cd95705d1e7f..8b6dc4d54fdc 100644 --- a/drivers/net/ethernet/intel/ice/ice_dpll.c +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c @@ -1843,6 +1843,8 @@ ice_dpll_init_rclk_pins(struct ice_pf *pf, struct ice_dpll_pin *pin, struct dpll_pin *parent; int ret, i; + if (WARN_ON((!vsi || !vsi->netdev))) + return -EINVAL; ret = ice_dpll_get_pins(pf, pin, start_idx, ICE_DPLL_RCLK_NUM_PER_PF, pf->dplls.clock_id); if (ret) @@ -1858,8 +1860,6 @@ ice_dpll_init_rclk_pins(struct ice_pf *pf, struct ice_dpll_pin *pin, if (ret) goto unregister_pins; } - if (WARN_ON((!vsi || !vsi->netdev))) - return -EINVAL; dpll_netdev_pin_set(vsi->netdev, pf->dplls.rclk.pin); return 0; -- 2.42.0

1 year, 2 months

2
1
0 0

stable-rc/linux-6.10.y: error: no member named 'st' in 'struct kvm_vcpu_arch'

by Miguel Ojeda

Hi Sasha, LoongArch, In a stable-rc/linux-6.10.y build-test today, I got: arch/loongarch/kvm/vcpu.c:575:15: error: no member named 'st' in 'struct kvm_vcpu_arch' 575 | vcpu->arch.st.guest_addr = 0; which I guess is triggered by missing prerequisites for commit 56f7eeae40de ("LoongArch: KVM: Invalidate guest steal time address on vCPU reset"). HTH! Cheers, Miguel

1 year, 2 months

4
6
0 0

[PATCH net] net: pcs: xpcs: fix the wrong register that was written back

by Jiawen Wu

The value is read from the register TXGBE_RX_GEN_CTL3, and it should be written back to TXGBE_RX_GEN_CTL3 when it changes some fields. Cc: stable(a)vger.kernel.org Fixes: f629acc6f210 ("net: pcs: xpcs: support to switch mode for Wangxun NICs") Signed-off-by: Jiawen Wu <jiawenwu(a)trustnetic.com> --- drivers/net/pcs/pcs-xpcs-wx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/pcs/pcs-xpcs-wx.c b/drivers/net/pcs/pcs-xpcs-wx.c index 19c75886f070..5f5cd3596cb8 100644 --- a/drivers/net/pcs/pcs-xpcs-wx.c +++ b/drivers/net/pcs/pcs-xpcs-wx.c @@ -109,7 +109,7 @@ static void txgbe_pma_config_1g(struct dw_xpcs *xpcs) txgbe_write_pma(xpcs, TXGBE_DFE_TAP_CTL0, 0); val = txgbe_read_pma(xpcs, TXGBE_RX_GEN_CTL3); val = u16_replace_bits(val, 0x4, TXGBE_RX_GEN_CTL3_LOS_TRSHLD0); - txgbe_write_pma(xpcs, TXGBE_RX_EQ_ATTN_CTL, val); + txgbe_write_pma(xpcs, TXGBE_RX_GEN_CTL3, val); txgbe_write_pma(xpcs, TXGBE_MPLLA_CTL0, 0x20); txgbe_write_pma(xpcs, TXGBE_MPLLA_CTL3, 0x46); -- 2.27.0

1 year, 2 months

3
2
0 0

[PATCH 5.10.y] mptcp: fix sometimes-uninitialized warning

by Matthieu Baerts (NGI0)

Nathan reported this issue: $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 LLVM_IAS=1 mrproper allmodconfig net/mptcp/subflow.o net/mptcp/subflow.c:877:6: warning: variable 'incr' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] 877 | if (WARN_ON_ONCE(offset > skb->len)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/asm-generic/bug.h:101:33: note: expanded from macro 'WARN_ON_ONCE' 101 | #define WARN_ON_ONCE(condition) ({ \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 102 | int __ret_warn_on = !!(condition); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103 | if (unlikely(__ret_warn_on)) \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 104 | __WARN_FLAGS(BUGFLAG_ONCE | \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 105 | BUGFLAG_TAINT(TAINT_WARN)); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 106 | unlikely(__ret_warn_on); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 107 | }) | ~~ net/mptcp/subflow.c:893:6: note: uninitialized use occurs here 893 | if (incr) | ^~~~ net/mptcp/subflow.c:877:2: note: remove the 'if' if its condition is always false 877 | if (WARN_ON_ONCE(offset > skb->len)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 878 | goto out; | ~~~~~~~~ net/mptcp/subflow.c:874:18: note: initialize the variable 'incr' to silence this warning 874 | u32 offset, incr, avail_len; | ^ | = 0 1 warning generated. As mentioned by Nathan, this issue is present because 5.10 does not include commit ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling"), which removed the use of 'incr' in the error path added by this change. This other commit does not really look suitable for stable, hence this dedicated patch for 5.10. Fixes: e93fa44f0714 ("mptcp: fix duplicate data handling") Reported-by: Nathan Chancellor <nathan(a)kernel.org> Closes: https://lore.kernel.org/20240928175524.GA1713144@thelio-3990X Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/subflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 8a0ef50c307c..843c61ebd421 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -871,7 +871,7 @@ static void mptcp_subflow_discard_data(struct sock *ssk, struct sk_buff *skb, struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); bool fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN; struct tcp_sock *tp = tcp_sk(ssk); - u32 offset, incr, avail_len; + u32 offset, incr = 0, avail_len; offset = tp->copied_seq - TCP_SKB_CB(skb)->seq; if (WARN_ON_ONCE(offset > skb->len)) -- 2.45.2

1 year, 2 months

2
1
0 0

[PATCH 5.10 v2 0/3] Re-adapt "bpf: Fix DEVMAP_HASH overflow check on 32-bit arches"

by Pu Lehui

Commit 70294d8bc31f ("bpf: Eliminate rlimit-based memory accounting for devmap maps") relies on the v5.11+ basic mechanism of memcg-based memory accounting [0]. The commit cannot be independently backported to the 5.10 stable branch, otherwise the related memory when creating devmap will be unrestricted and the associated bpf selftest map_ptr will fail. Let's roll back to rlimit-based memory accounting mode for devmap and re-adapt the commit 225da02acdc9 ("bpf: Fix DEVMAP_HASH overflow check on 32-bit arches") to the 5.10 stable branch. Link: https://lore.kernel.org/bpf/20201201215900.3569844-1-guro@fb.com [0] Pu Lehui (2): Revert "bpf: Fix DEVMAP_HASH overflow check on 32-bit arches" Revert "bpf: Eliminate rlimit-based memory accounting for devmap maps" Toke Høiland-Jørgensen (1): bpf: Fix DEVMAP_HASH overflow check on 32-bit arches kernel/bpf/devmap.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) -- 2.34.1

1 year, 2 months

2
4
0 0

[PATCH 5.10.y 0/3] x86: Complete backports for x86_match_cpu()

by Ricardo Neri

Hi, Upstream commit 93022482b294 ("x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL") introduced a flags member to struct x86_cpu_id. Bit 0 of x86_cpu.id.flags must be set to 1 for x86_match_cpu() to work correctly. This upstream commit has been backported to 5.10.y. Callers that use the X86_MATCH_*() family of macros to compose the argument of x86_match_cpu() function correctly. Callers that use their own custom mechanisms may not work if they fail to set x86_cpu_id.flags correctly. There are three remaining callers in 5.10.y that use their own mechanisms: a) setup_pcid(), b) rapl_msr_probe(), and c) goodix_add_acpi_gpio_ mappings(). a) caused a regression that Thomas Lindroth reported in [1]. b) works by luck but it still populates its x86_cpu_id[] array incorrectly. I am not aware of any reports on c), but inspecting the code reveals that it will fail to identify INTEL_FAM6_ATOM_SILVERMONT for the reason described above. I backported three patches that fix these bugs in mainline. Hopefully the authors and/or maintainers can ack the backports? I tested patches 2/3 and 3/3 on Tiger Lake, Alder Lake, and Meteor Lake systems as the two involved callers behave differently on these systems. I wrote the testing details in each patch separately. I could not test patch 1/3 because I do not have access to Bay Trail hardware. Thanks and BR, Ricardo [1]. https://lore.kernel.org/all/eb709d67-2a8d-412f-905d-f3777d897bfa@gmail.com/ Hans de Goede (1): Input: goodix - use the new soc_intel_is_byt() helper Sumeet Pawnikar (1): powercap: RAPL: fix invalid initialization for pl4_supported field Tony Luck (1): x86/mm: Switch to new Intel CPU model defines arch/x86/mm/init.c | 16 ++++++---------- drivers/input/touchscreen/goodix.c | 18 ++---------------- drivers/powercap/intel_rapl_msr.c | 2 +- 3 files changed, 9 insertions(+), 27 deletions(-) -- 2.34.1

1 year, 2 months

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024