June 2025 - Linux-stable-mirror

[PATCH v2 5.10.y] net/ipv4: fix type mismatch in inet_ehash_locks_alloc() causing build failure

by Eliav Farber

Fix compilation warning: In file included from ./include/linux/kernel.h:15, from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12: net/ipv4/inet_hashtables.c: In function ‘inet_ehash_locks_alloc’: ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’ 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’ 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro ‘__careful_cmp’ 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~ net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro ‘max’ 946 | nblocks = max(nblocks, num_online_nodes() * PAGE_SIZE / locksz); | ^~~ CC block/badblocks.o When warnings are treated as errors, this causes the build to fail. The issue is a type mismatch between the operands passed to the max() macro. Here, nblocks is an unsigned int, while the expression num_online_nodes() * PAGE_SIZE / locksz is promoted to unsigned long. This happens because: - num_online_nodes() returns int - PAGE_SIZE is typically defined as an unsigned long (depending on the architecture) - locksz is unsigned int The resulting arithmetic expression is promoted to unsigned long. Thus, the max() macro compares values of different types: unsigned int vs unsigned long. This issue was introduced in commit f8ece40786c9 ("tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()") during the update from kernel v5.10.237 to v5.10.238. It does not exist in newer kernel branches (e.g., v5.15.185 and all 6.x branches), because they include commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness.") Fix the issue by using max_t(unsigned int, ...) to explicitly cast both operands to the same type, avoiding the type mismatch and ensuring correctness. Fixes: f8ece40786c9 ("tcp: bring back NUMA dispersion in inet_ehash_locks_alloc()") Signed-off-by: Eliav Farber <farbere(a)amazon.com> --- V1 -> V2: Use upstream commit SHA1 in reference net/ipv4/inet_hashtables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c index fea74ab2a4be..ac2d185c04ef 100644 --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -943,7 +943,7 @@ int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo) nblocks = max(2U * L1_CACHE_BYTES / locksz, 1U) * num_possible_cpus(); /* At least one page per NUMA node. */ - nblocks = max(nblocks, num_online_nodes() * PAGE_SIZE / locksz); + nblocks = max_t(unsigned int, nblocks, num_online_nodes() * PAGE_SIZE / locksz); nblocks = roundup_pow_of_two(nblocks); -- 2.47.1

2 weeks, 1 day

2
1
0 0

[PATCH] dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()

by Qiu-ji Chen

Fixed a flag reuse bug in the mtk_cqdma_tx_status() function. Fixes: 157ae5ffd76a ("dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505270641.MStzJUfU-lkp@intel.com/ Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- drivers/dma/mediatek/mtk-cqdma.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c index 47c8adfdc155..f7b870d2ca90 100644 --- a/drivers/dma/mediatek/mtk-cqdma.c +++ b/drivers/dma/mediatek/mtk-cqdma.c @@ -441,18 +441,19 @@ static enum dma_status mtk_cqdma_tx_status(struct dma_chan *c, struct mtk_cqdma_vdesc *cvd; struct virt_dma_desc *vd; enum dma_status ret; - unsigned long flags; + unsigned long pc_flags; + unsigned long vc_flags; size_t bytes = 0; ret = dma_cookie_status(c, cookie, txstate); if (ret == DMA_COMPLETE || !txstate) return ret; - spin_lock_irqsave(&cvc->pc->lock, flags); - spin_lock_irqsave(&cvc->vc.lock, flags); + spin_lock_irqsave(&cvc->pc->lock, pc_flags); + spin_lock_irqsave(&cvc->vc.lock, vc_flags); vd = mtk_cqdma_find_active_desc(c, cookie); - spin_unlock_irqrestore(&cvc->vc.lock, flags); - spin_unlock_irqrestore(&cvc->pc->lock, flags); + spin_unlock_irqrestore(&cvc->vc.lock, vc_flags); + spin_unlock_irqrestore(&cvc->pc->lock, pc_flags); if (vd) { cvd = to_cqdma_vdesc(vd); -- 2.34.1

2 weeks, 1 day

2
5
0 0

[PATCH] gpio: loongson-64bit: Correct Loongson-7A2000 ACPI GPIO access mode

by Binbin Zhou

According to the description of the Loongson-7A2000 ACPI GPIO register in the manual, its access mode should be BIT_CTRL_MODE, otherwise there maybe some unpredictable behavior. Cc: stable(a)vger.kernel.org Fixes: 44fe79020b91 ("gpio: loongson-64bit: Add more gpio chip support") Signed-off-by: Binbin Zhou <zhoubinbin(a)loongson.cn> --- drivers/gpio/gpio-loongson-64bit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-loongson-64bit.c b/drivers/gpio/gpio-loongson-64bit.c index 26227669f026..70a01c5b8ad1 100644 --- a/drivers/gpio/gpio-loongson-64bit.c +++ b/drivers/gpio/gpio-loongson-64bit.c @@ -268,7 +268,7 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls7a2000_data0 = { /* LS7A2000 ACPI GPIO */ static const struct loongson_gpio_chip_data loongson_gpio_ls7a2000_data1 = { .label = "ls7a2000_gpio", - .mode = BYTE_CTRL_MODE, + .mode = BIT_CTRL_MODE, .conf_offset = 0x4, .in_offset = 0x8, .out_offset = 0x0, base-commit: e0d4a0f1d066f14522049e827107a577444d9183 -- 2.47.1

2 weeks, 1 day

3
2
0 0

[PATCH v1] usb: acpi: fix device link removal

by Heikki Krogerus

The device link to the USB4 host interface has to be removed manually since it's no longer auto removed. Fixes: 623dae3e7084 ("usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links") Cc: stable(a)vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> --- drivers/usb/core/hub.c | 3 +++ drivers/usb/core/usb-acpi.c | 4 +++- include/linux/usb.h | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 770d1e91183c..14229dcb0952 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2337,6 +2337,9 @@ void usb_disconnect(struct usb_device **pdev) usb_remove_ep_devs(&udev->ep0); usb_unlock_device(udev); + if (udev->usb4_link) + device_link_del(udev->usb4_link); + /* Unregister the device. The device driver is responsible * for de-configuring the device and invoking the remove-device * notifier chain (used by usbfs and possibly others). diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c index ea1ce8beb0cb..489dbdc96f94 100644 --- a/drivers/usb/core/usb-acpi.c +++ b/drivers/usb/core/usb-acpi.c @@ -157,7 +157,7 @@ EXPORT_SYMBOL_GPL(usb_acpi_set_power_state); */ static int usb_acpi_add_usb4_devlink(struct usb_device *udev) { - const struct device_link *link; + struct device_link *link; struct usb_port *port_dev; struct usb_hub *hub; @@ -188,6 +188,8 @@ static int usb_acpi_add_usb4_devlink(struct usb_device *udev) dev_dbg(&port_dev->dev, "Created device link from %s to %s\n", dev_name(&port_dev->child->dev), dev_name(nhi_fwnode->dev)); + udev->usb4_link = link; + return 0; } diff --git a/include/linux/usb.h b/include/linux/usb.h index 1b2545b4363b..92c752f5446f 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -614,6 +614,7 @@ struct usb3_lpm_parameters { * FIXME -- complete doc * @authenticated: Crypto authentication passed * @tunnel_mode: Connection native or tunneled over USB4 + * @usb4_link: device link to the USB4 host interface * @lpm_capable: device supports LPM * @lpm_devinit_allow: Allow USB3 device initiated LPM, exit latency is in range * @usb2_hw_lpm_capable: device can perform USB2 hardware LPM @@ -724,6 +725,7 @@ struct usb_device { unsigned reset_resume:1; unsigned port_is_suspended:1; enum usb_link_tunnel_mode tunnel_mode; + struct device_link *usb4_link; int slot_id; struct usb2_lpm_parameters l1_params; -- 2.47.2

2 weeks, 1 day

2
1
0 0

[PATCH v3 2/3] udmabuf: use sgtable-based scatterlist wrappers

by Marek Szyprowski

Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgtable's nents. Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access") CC: stable(a)vger.kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Acked-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> --- drivers/dma-buf/udmabuf.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 7eee3eb47a8e..c9d0c68d2fcb 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -264,8 +264,7 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, ubuf->sg = NULL; } } else { - dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, - direction); + dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction); } return ret; @@ -280,7 +279,7 @@ static int end_cpu_udmabuf(struct dma_buf *buf, if (!ubuf->sg) return -EINVAL; - dma_sync_sg_for_device(dev, ubuf->sg->sgl, ubuf->sg->nents, direction); + dma_sync_sgtable_for_device(dev, ubuf->sg, direction); return 0; } -- 2.34.1

2 weeks, 1 day

2
4
0 0

[PATCH 0/3] x86: Fix some bugs related to ITS mitigation

by Juergen Gross

Running as a Xen PV guest uncovered some bugs when ITS mitigation is active. Juergen Gross (3): x86/execmem: don't use PAGE_KERNEL protection for code pages x86/mm/pat: don't collapse pages without PSE set x86/alternative: make kernel ITS thunks read-only arch/x86/kernel/alternative.c | 16 ++++++++++++++++ arch/x86/mm/init.c | 2 +- arch/x86/mm/pat/set_memory.c | 3 +++ 3 files changed, 20 insertions(+), 1 deletion(-) -- 2.43.0

2 weeks, 1 day

6
17
0 0

Re: [PATCH 5.10.y 2/3] rtc: Make rtc_time64_to_tm() support dates before 1970

by Uwe Kleine-König

Hello Cassio, thanks for your input. On Tue, Jun 10, 2025 at 09:31:48PM +0100, Cassio Neri wrote: > Although untested, I'm pretty sure that with very small changes, the > previous revision (1d1bb12) can handle dates prior to 1970-01-01 with no > need to add extra branches or arithmetic operations. Indeed, 1d1bb12 > contains: > > <code> > /* time must be positive */ > days = div_s64_rem(time, 86400, &secs); > > /* day of the week, 1970-01-01 was a Thursday */ > tm->tm_wday = (days + 4) % 7; > > /* long comments */ > > udays = ((u32) days) + 719468; > </code> > > This could have been changed to: > > <code> > /* time must be >= -719468 * 86400 which corresponds to 0000-03-01 */ > udays = div_u64_rem(time + 719468 * 86400, 86400, &secs); > > /* day of the week, 0000-03-01 was a Wednesday (in the proleptic Gregorian > calendar) */ > tm->tm_wday = (days + 3) % 7; > > /* long comments */ > </code> > > Indeed, the addition of 719468 * 86400 to `time` makes `days` to be 719468 > more than it should be. Therefore, in the calculation of `udays`, the > addition of 719468 becomes unnecessary and thus, `udays == days`. Moreover, > this means that `days` can be removed altogether and replaced by `udays`. > (Not the other way around because in the remaining code `udays` must be > u32.) > > Now, 719468 % 7 = 1 and thus tm->wday is 1 day after what it should be and > we correct that by adding 3 instead of 4. > > Therefore, I suggest these changes on top of 1d1bb12 instead of those made > in 7df4cfe. Since you're working on this, can I please kindly suggest two > other changes? It's to late for "instead", and we're discussing a backport to stable for a commit that is already in v6.16-rc1. While your concerns are correct (though I didn't check the details yet), I claim that 7df4cfef8b35 is correct and it's the right thing to backport that today. Incremental changes can then go in the development version (and backported if deemed necessary). > 1) Change the reference provided in the long comment. It should say, "The > following algorithm is, basically, Figure 12 of Neri and Schneider [1]" and > [1] should refer to the published article: > > Neri C, Schneider L. Euclidean affine functions and their application to > calendar algorithms. Softw Pract Exper. 2023;53(4):937-970. doi: > 10.1002/spe.3172 > https://doi.org/10.1002/spe.3172 > > The article is much better written and clearer than the pre-print currently > referred to. I'll add that to my todo list. (that = improving rtc_time64_to_tm() and reading your paper :-) > 2) Function rtc_time64_to_tm_test_date_range in drivers/rtc/lib_test.c, is > a kunit test that checks the result for everyday in a 160000 years range > starting at 1970-01-01. It'd be nice if this test is adapted to the new > code and starts at 1900-01-01 (technically, it could start at 0000-03-01 > but since tm->year counts from 1900, it would be weird to see tm->year == > -1900 to mean that the calendar year is 0.) Also 160000 is definitely an > overkill (my bad!) and a couple of thousands of years, say 3000, should be > more than safe for anyone. :-) I already did 2), see https://git.kernel.org/linus/ccb2dba3c19f. Best regards Uwe

2 weeks, 1 day

1
0
0 0

Mailbox Alert: Storage Limit Almost Reached

by lists.linaro.org 通知

2 weeks, 1 day

1
0
0 0

[PATCH] x86/mm: Disable INVLPGB when PTI is enabled

by Dave Hansen

From: Dave Hansen <dave.hansen(a)linux.intel.com> PTI uses separate ASIDs (aka. PCIDs) for kernel and user address spaces. When the kernel needs to flush the user address space, it just sets a bit in a bitmap and then flushes the entire PCID on the next switch to userspace. But, this bitmap is a single 'unsigned long' which is plenty for all 6 dynamic ASIDs. But, unfortunately, the INVLPGB support brings along a bunch more user ASIDs, as many as ~2k more. The bitmap can't address that many. Fortunately, the bitmap is only needed for PTI and all the CPUs with INVLPGB are AMD CPUs that aren't vulnerable to Meltdown and don't need PTI. The only way someone can run into an issue in practice is by booting with pti=on on a newer AMD CPU. Disable INVLPGB if PTI is enabled. Avoid overrunning the small bitmap. Note: this will be fixed up properly by making the bitmap bigger. For now, just avoid the mostly theoretical bug. Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes") Cc: stable(a)vger.kernel.org Cc: Rik van Riel <riel(a)surriel.com> Cc: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> --- b/arch/x86/mm/pti.c | 5 +++++ 1 file changed, 5 insertions(+) diff -puN arch/x86/mm/pti.c~no-INVLPGB-plus-KPTI arch/x86/mm/pti.c --- a/arch/x86/mm/pti.c~no-INVLPGB-plus-KPTI 2025-06-10 15:02:14.439554339 -0700 +++ b/arch/x86/mm/pti.c 2025-06-10 15:09:47.713198206 -0700 @@ -98,6 +98,11 @@ void __init pti_check_boottime_disable(v return; setup_force_cpu_cap(X86_FEATURE_PTI); + + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) { + pr_debug("PTI enabled, disabling INVLPGB\n"); + setup_clear_cpu_cap(X86_FEATURE_INVLPGB); + } } static int __init pti_parse_cmdline(char *arg) _

2 weeks, 1 day

3
2
0 0

[PATCH v2] mm/memory-tier: Fix abstract distance calculation overflow

by Li Zhijian

In mt_perf_to_adistance(), the calculation of abstract distance (adist) involves multiplying several int values including MEMTIER_ADISTANCE_DRAM. ``` *adist = MEMTIER_ADISTANCE_DRAM * (perf->read_latency + perf->write_latency) / (default_dram_perf.read_latency + default_dram_perf.write_latency) * (default_dram_perf.read_bandwidth + default_dram_perf.write_bandwidth) / (perf->read_bandwidth + perf->write_bandwidth); ``` Since these values can be large, the multiplication may exceed the maximum value of an int (INT_MAX) and overflow (Our platform did), leading to an incorrect adist. User-visible impact: The memory tiering subsystem will misinterpret slow memory (like CXL) as faster than DRAM, causing inappropriate demotion of pages from CXL (slow memory) to DRAM (fast memory). For example, we will see the following demotion chains from the dmesg, where Node0,1 are DRAM, and Node2,3 are CXL node: Demotion targets for Node 0: null Demotion targets for Node 1: null Demotion targets for Node 2: preferred: 0-1, fallback: 0-1 Demotion targets for Node 3: preferred: 0-1, fallback: 0-1 Change MEMTIER_ADISTANCE_DRAM to be a long constant by writing it with the 'L' suffix. This prevents the overflow because the multiplication will then be done in the long type which has a larger range. Fixes: 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT") Cc: stable(a)vger.kernel.org Reviewed-by: Huang Ying <ying.huang(a)linux.alibaba.com> Acked-by: Balbir Singh <balbirs(a)nvidia.com> Reviewed-by: Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> --- V2: Document the 'User-visible impact' # Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memory-tiers.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h index 0dc0cf2863e2..7a805796fcfd 100644 --- a/include/linux/memory-tiers.h +++ b/include/linux/memory-tiers.h @@ -18,7 +18,7 @@ * adistance value (slightly faster) than default DRAM adistance to be part of * the same memory tier. */ -#define MEMTIER_ADISTANCE_DRAM ((4 * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1)) +#define MEMTIER_ADISTANCE_DRAM ((4L * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1)) struct memory_tier; struct memory_dev_type { -- 2.41.0

2 weeks, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025