- Linux-stable-mirror - lists.linaro.org

回复:6.12.50 regression: netem: cannot mix duplicating netems with other netems in tree.

by zyc zyc

Hello, Resend my last email without HTML. ---- zyc zyc <zyc199902(a)zohomail.cn> 在 Sat, 2025-11-29 18:57:01 写到：--- > Hello, maintainer > > I would like to report what appears to be a regression in 6.12.50 kernel release related to netem. > It rejects our configuration with the message: > Error: netem: cannot mix duplicating netems with other netems in tree. > > This breaks setups that previously worked correctly for many years. > > > Our team uses multiple netem qdiscs in the same HTB branch, arranged in a parallel fashion using a prio fan-out. Each branch of the prio qdisc has its own distinct netem instance with different duplication characteristics. > > This is used to emulate our production conditions where a single logical path fans out into two downstream segments, for example: > > two ECMP next hops with different misbehaviour characteristics, or > > > an HA firewall cluster where only one node is replaying frames, or > > > two LAG / ToR paths where one path intermittently duplicates packets. > > > In our environments, only a subset of flows are affected, and different downstream devices may cause different styles of duplication. > This regression breaks existing automated tests, training environments, and network simulation pipelines. > > I would be happy to provide our reproducer if needed. > > Thank you for your time and for maintaining Linux kernel. > > > > Best regards, > zyc > > >

1 day, 23 hours

2
4
0 0

[PATCH] drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors

by Luca Ceresoli

On hardware based on Toradex Verdin AM62 the recovery mechanism added by commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism") has been reported [0] to make the display turn on and off and and the kernel logging "Unexpected link status 0x01". According to the report, the error recovery mechanism is triggered by the PLL_UNLOCK error going active. Analysis suggested the board is unable to provide the correct DSI clock neede by the SN65DSI84, to which the TI SN65DSI84 reacts by raising the PLL_UNLOCK, while the display still works apparently without issues. On other hardware, where all the clocks are within the components specifications, the PLL_UNLOCK bit does not trigger while the display is in normal use. It can trigger for e.g. electromagnetic interference, which is a transient event and exactly the reason why the error recovery mechanism has been implemented. Idelly the PLL_UNLOCK bit could be ignored when working out of specification, but this requires to detect in software whether it triggers because the device is working out of specification but visually correctly for the user or for good reasons (e.g. EMI, or even because working out of specifications but compromising the visual output). The ongoing analysis as of this writing [1][2] has not yet found a way for the driver to discriminate among the two cases. So as a temporary measure mask the PLL_UNLOCK error bit unconditionally. [0] https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… [1] https://lore.kernel.org/all/b71e941c-fc8a-4ac1-9407-0fe7df73b412@gmail.com/ [2] https://lore.kernel.org/all/20251125103900.31750-1-francesco@dolcini.it/ Closes: https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… Cc: stable(a)vger.kernel.org # 6.15+ Co-developed-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> --- Francesco, Emanuele, João: can you please apply this patch and report whether the display on the affected boards gets back to working as before? Cc: João Paulo Gonçalves <jpaulo.silvagoncalves(a)gmail.com> Cc: Francesco Dolcini <francesco(a)dolcini.it> Cc: Emanuele Ghidoli <ghidoliemanuele(a)gmail.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 033c44326552..fffb47b62f43 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -429,7 +429,14 @@ static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx) */ ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat); - if (ret || irq_stat) { + + /* + * Some hardware (Toradex Verdin AM62) is known to report the + * PLL_UNLOCK error interrupt while working without visible + * problems. In lack of a reliable way to discriminate such cases + * from user-visible PLL_UNLOCK cases, ignore that bit entirely. + */ + if (ret || irq_stat & ~REG_IRQ_STAT_CHA_PLL_UNLOCK) { /* * IRQ acknowledged is not always possible (the bridge can be in * a state where it doesn't answer anymore). To prevent an @@ -654,7 +661,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, if (ctx->irq) { /* Enable irq to detect errors */ regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN); - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff); + regmap_write(ctx->regmap, REG_IRQ_EN, 0xff & ~REG_IRQ_EN_CHA_PLL_UNLOCK_EN); } else { /* Use the polling task */ sn65dsi83_monitor_start(ctx); --- base-commit: c884ee70b15a8d63184d7c1e02eba99676a6fcf7 change-id: 20251126-drm-ti-sn65dsi83-ignore-pll-unlock-4a28aa29eb5c Best regards, -- Luca Ceresoli <luca.ceresoli(a)bootlin.com>

2 days, 1 hour

3
4
0 0

[PATCH v3] gpio: regmap: Fix memleak in gpio_remap_register

by Wentao Guan

We should call gpiochip_remove(chip) to free the resource alloced by gpiochip_add_data(chip, gpio) after the err path. Fixes: 553b75d4bfe9 ("gpio: regmap: Allow to allocate regmap-irq device") Fixes: ae495810cffe ("gpio: regmap: add the .fixed_direction_output configuration parameter") CC: stable(a)vger.kernel.org Co-developed-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> --- changelog in v3: Add dependency fixes tag which suggested by Andy Shevchenko. changelog in v2: 1. format commit message. 2. rebase to mainline now. --- --- drivers/gpio/gpio-regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c index f4267af00027e..c64805dcb9f88 100644 --- a/drivers/gpio/gpio-regmap.c +++ b/drivers/gpio/gpio-regmap.c @@ -328,7 +328,7 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config config->regmap_irq_line, config->regmap_irq_flags, 0, config->regmap_irq_chip, &gpio->irq_chip_data); if (ret) - goto err_free_bitmap; + goto err_remove_gpiochip; irq_domain = regmap_irq_get_domain(gpio->irq_chip_data); } else -- 2.20.1

2 days, 1 hour

3
2
0 0

[PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison

by Maciej Wieczor-Retman

From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> A KASAN tag mismatch, possibly causing a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. It was reported on arm64 and reproduced on x86. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in preparation for the actual fix. Changelog v1 (after splitting of from the KASAN series): - Rewrite first paragraph of the patch message to point at the user impact of the issue. - Move helper to common.c so it can be compiled in all KASAN modes. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: <stable(a)vger.kernel.org> # 6.1+ Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> --- Changelog v3: - Redo the patch after applying Andrey's comments to align the code more with what's already in include/linux/kasan.h Changelog v2: - Redo the whole patch so it's an actual refactor. include/linux/kasan.h | 15 +++++++++++++++ mm/kasan/common.c | 17 +++++++++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 6d7972bb390c..cde493cb7702 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -615,6 +615,16 @@ static __always_inline void kasan_poison_vmalloc(const void *start, __kasan_poison_vmalloc(start, size); } +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags); +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms, flags); +} + #else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void *start, static inline void kasan_poison_vmalloc(const void *start, unsigned long size) { } +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/common.c b/mm/kasan/common.c index d4c14359feaf..1ed6289d471a 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -28,6 +28,7 @@ #include <linux/string.h> #include <linux/types.h> #include <linux/bug.h> +#include <linux/vmalloc.h> #include "kasan.h" #include "../slab.h" @@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip) } return true; } + +#ifdef CONFIG_KASAN_VMALLOC +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + unsigned long size; + void *addr; + int area; + + for (area = 0 ; area < nr_vms ; area++) { + size = vms[area]->size; + addr = vms[area]->addr; + vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags); + } +} +#endif diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 22a73a087135..33e705ccafba 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4872,9 +4872,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area = 0; area < nr_vms; area++) - vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL); kfree(vas); return vms; -- 2.52.0

2 days, 2 hours

3
2
0 0

6.17.9 / 6.18 AMDGPU DMCUB Error

by Neil Gammie

Hello all, please forgive me if this issue is already known, but I couldn't find any reference to it with regard to the 6.17.9 kernel. Anyway, when updating from 6.17.8 to 6.17.9, the following error is raised on every boot: Dec 04 14:44:20 P14s kernel: amdgpu: Topology: Add dGPU node [0x1638:0x1002] Dec 04 14:44:20 P14s kernel: kfd kfd: amdgpu: added device 1002:1638 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: Runtime PM not available Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: [drm] Using custom brightness curve Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] Registered 4 planes with drm panic Dec 04 14:44:20 P14s kernel: [drm] Initialized amdgpu 3.64.0 for 0000:07:00.0 on minor 1 Dec 04 14:44:20 P14s kernel: fbcon: amdgpudrmfb (fb0) is primary device Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Dec 04 14:44:21 P14s kernel: amdgpu 0000:07:00.0: [drm] fb0: amdgpudrmfb frame buffer device Setup is as follows: Hardware: ThinkPad P14s Gen 2 AMD Processor: AMD Ryzen™ 7 PRO 5850U OS: Arch Linux AMD Firmware: linux-firmware-amdgpu 20251125 Running a bisection gives the following: git bisect start # status: waiting for both good and bad commits # good: [8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae] Linux 6.17.8 git bisect good 8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae # status: waiting for bad commit, 1 good commit known # bad: [1bfd0faa78d09eb41b81b002e0292db0f3e75de0] Linux 6.17.9 git bisect bad 1bfd0faa78d09eb41b81b002e0292db0f3e75de0 # bad: [92ef36a75fbb56a02a16b141fe684f64fb2b1cb9] lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN git bisect bad 92ef36a75fbb56a02a16b141fe684f64fb2b1cb9 # bad: [aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d] sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto git bisect bad aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d # bad: [b3b288206a1ea7e21472f8d1c7834ebface9bb33] drm/amdkfd: fix suspend/resume all calls in mes based eviction path git bisect bad b3b288206a1ea7e21472f8d1c7834ebface9bb33 # good: [ac486718d6cc96e07bc67094221e682ba5ea6f76] drm/amd/pm: Use pm_display_cfg in legacy DPM (v2) git bisect good ac486718d6cc96e07bc67094221e682ba5ea6f76 # bad: [1009f007b3afba93082599e263b3807d05177d53] RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors git bisect bad 1009f007b3afba93082599e263b3807d05177d53 # bad: [ccd8af579101ca68f1fba8c9e055554202381cab] drm/amd: Disable ASPM on SI git bisect bad ccd8af579101ca68f1fba8c9e055554202381cab # bad: [e95425b6df29cc88fac7d0d77aa38a5a131dbf45] drm/amd/pm: Disable MCLK switching on SI at high pixel clocks git bisect bad e95425b6df29cc88fac7d0d77aa38a5a131dbf45 # bad: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too git bisect bad 5ee434b55134c24df7ad426d40fe28c6542fab4d # first bad commit: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too The error still occurs in 6.18, but reverting the above bad commit removes it. Although an error is reported, the system still boots to the graphical interface and appears to function normally, although I have neither benchmarked graphics performance or used the system for an extended period after the error has been flagged. Yours faithfully, Neil Gammie

2 days, 2 hours

1
0
0 0

[PATCH 6.1.y] ksmbd: fix out-of-bounds in parse_sec_desc()

by Rajani Kantha

From: Namjae Jeon <linkinjeon(a)kernel.org> commit d6e13e19063db24f94b690159d0633aaf72a0f03 upstream. If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size. Cc: stable(a)vger.kernel.org Reported-by: Norbert Szetei <norbert(a)doyensec.com> Tested-by: Norbert Szetei <norbert(a)doyensec.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Rajani Kantha <681739313(a)139.com> --- fs/smb/server/smbacl.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/smb/server/smbacl.c b/fs/smb/server/smbacl.c index 90c5e3edbf46..5c05f0e8b6ea 100644 --- a/fs/smb/server/smbacl.c +++ b/fs/smb/server/smbacl.c @@ -815,6 +815,13 @@ static int parse_sid(struct smb_sid *psid, char *end_of_acl) return -EINVAL; } + if (!psid->num_subauth) + return 0; + + if (psid->num_subauth > SID_MAX_SUB_AUTHORITIES || + end_of_acl < (char *)psid + 8 + sizeof(__le32) * psid->num_subauth) + return -EINVAL; + return 0; } @@ -856,6 +863,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type = cpu_to_le16(DACL_PRESENT); if (pntsd->osidoffset) { + if (le32_to_cpu(pntsd->osidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(owner_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d parsing Owner SID\n", __func__, rc); @@ -871,6 +881,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, } if (pntsd->gsidoffset) { + if (le32_to_cpu(pntsd->gsidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(group_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d mapping Owner SID to gid\n", @@ -892,6 +905,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type |= cpu_to_le16(DACL_PROTECTED); if (dacloffset) { + if (dacloffset < sizeof(struct smb_ntsd)) + return -EINVAL; + parse_dacl(user_ns, dacl_ptr, end_of_acl, owner_sid_ptr, group_sid_ptr, fattr); } -- 2.17.1

2 days, 2 hours

1
0
0 0

[PATCH 6.1] net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

by Chen Yu

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Chen Yu <xnguchen(a)sina.cn> --- drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c index baba204ad62f..2ac91fe2a79b 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i) if (i > table->entry_count) return -ERANGE; - memmove(entries + i * entry_size, entries + (i + 1) * entry_size, - (table->entry_count - i) * entry_size); + if (i + 1 < table->entry_count) { + memmove(entries + i * entry_size, entries + (i + 1) * entry_size, + (table->entry_count - i - 1) * entry_size); + } table->entry_count--; -- 2.17.1

2 days, 4 hours

1
0
0 0

[PATCH v2 1/3] dm-pcache: advance slot index before writing slot

by Dongsheng Yang

In dm-pcache, in order to ensure crash-consistency, a dual-copy scheme is used to alternately update metadata, and there is a slot index that records the current slot. However, in the write path the current implementation writes directly to the current slot indexed by slot index, and then advances the slot — which ends up overwriting the existing slot, violating the crash-consistency guarantee. This patch fixes that behavior, preventing metadata from being overwritten incorrectly. In addition, this patch add a missing pmem_wmb() after memcpy_flushcache(). Signed-off-by: Dongsheng Yang <dongsheng.yang(a)linux.dev> Reviewed-by: Zheng Gu <cengku(a)gmail.com> Cc: stable(a)vger.kernel.org # 6.18 --- drivers/md/dm-pcache/cache.c | 8 ++++---- drivers/md/dm-pcache/cache_segment.c | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/md/dm-pcache/cache.c b/drivers/md/dm-pcache/cache.c index 698697a7a73c..d4385d76ac36 100644 --- a/drivers/md/dm-pcache/cache.c +++ b/drivers/md/dm-pcache/cache.c @@ -21,10 +21,10 @@ static void cache_info_write(struct pcache_cache *cache) cache_info->header.crc = pcache_meta_crc(&cache_info->header, sizeof(struct pcache_cache_info)); + cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; memcpy_flushcache(get_cache_info_addr(cache), cache_info, sizeof(struct pcache_cache_info)); - - cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; + pmem_wmb(); } static void cache_info_init_default(struct pcache_cache *cache); @@ -93,10 +93,10 @@ void cache_pos_encode(struct pcache_cache *cache, pos_onmedia.header.seq = seq; pos_onmedia.header.crc = cache_pos_onmedia_crc(&pos_onmedia); + *index = (*index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(pos_onmedia_addr, &pos_onmedia, sizeof(struct pcache_cache_pos_onmedia)); pmem_wmb(); - - *index = (*index + 1) % PCACHE_META_INDEX_MAX; } int cache_pos_decode(struct pcache_cache *cache, diff --git a/drivers/md/dm-pcache/cache_segment.c b/drivers/md/dm-pcache/cache_segment.c index f0b58980806e..ae57cc261422 100644 --- a/drivers/md/dm-pcache/cache_segment.c +++ b/drivers/md/dm-pcache/cache_segment.c @@ -26,11 +26,11 @@ static void cache_seg_info_write(struct pcache_cache_segment *cache_seg) seg_info->header.seq++; seg_info->header.crc = pcache_meta_crc(&seg_info->header, sizeof(struct pcache_segment_info)); + cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; + seg_info_addr = get_seg_info_addr(cache_seg); memcpy_flushcache(seg_info_addr, seg_info, sizeof(struct pcache_segment_info)); pmem_wmb(); - - cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; mutex_unlock(&cache_seg->info_lock); } @@ -129,10 +129,10 @@ static void cache_seg_ctrl_write(struct pcache_cache_segment *cache_seg) cache_seg_gen.header.crc = pcache_meta_crc(&cache_seg_gen.header, sizeof(struct pcache_cache_seg_gen)); + cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(get_cache_seg_gen_addr(cache_seg), &cache_seg_gen, sizeof(struct pcache_cache_seg_gen)); pmem_wmb(); - - cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; } static void cache_seg_ctrl_init(struct pcache_cache_segment *cache_seg) -- 2.43.0

2 days, 4 hours

1
2
0 0

[PATCH AUTOSEL 6.18-6.17] crypto: ccp - Add support for PCI device 0x115A

by Sasha Levin

From: "Mario Limonciello (AMD)" <superm1(a)kernel.org> [ Upstream commit 9fc6290117259a8dbf8247cb54559df62fd1550f ] PCI device 0x115A is similar to pspv5, except it doesn't have platform access mailbox support. Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Comprehensive Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `crypto: ccp - Add support for PCI device 0x115A` **Key Information:** - PCI device 0x115A is a new AMD security processor variant - The commit message states it's "similar to pspv5, except it doesn't have platform access mailbox support" - Signed off by Mario Limonciello (AMD engineer) and Tom Lendacky (AMD) - Merged by Herbert Xu (crypto maintainer) **Tags Present:** - `Signed-off-by`: 3 (proper sign-off chain) - `Acked-by`: Tom Lendacky (driver maintainer acknowledgment) - **NO** `Cc: stable(a)vger.kernel.org` tag - **NO** `Fixes:` tag (this is expected - it's not fixing a bug, it's enabling hardware) ### 2. CODE CHANGE ANALYSIS The commit adds: **A) New `pspv7` structure (~10 lines):** ```c static const struct psp_vdata pspv7 = { .tee = &teev2, .cmdresp_reg = 0x10944, .cmdbuff_addr_lo_reg = 0x10948, .cmdbuff_addr_hi_reg = 0x1094c, .bootloader_info_reg = 0x109ec, .feature_reg = 0x109fc, .inten_reg = 0x10510, .intsts_reg = 0x10514, }; ``` This is **identical to pspv5** except it omits the `.platform_access = &pa_v2` field. This is the explicit difference mentioned in the commit message. **B) New `dev_vdata[9]` entry (~6 lines):** ```c { /* 9 */ .bar = 2, #ifdef CONFIG_CRYPTO_DEV_SP_PSP .psp_vdata = &pspv7, #endif }, ``` **C) New PCI device ID entry (1 line):** ```c { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, ``` ### 3. CLASSIFICATION **This is a NEW DEVICE ID addition** - one of the explicitly allowed exceptions for stable kernel backports. The commit: - Does NOT add new features or APIs - Does NOT change existing behavior - Only enables existing PSP driver functionality on new hardware - Uses established patterns already in the driver ### 4. SCOPE AND RISK ASSESSMENT **Change size:** ~17 lines total - Small, contained data-only change - No logic changes whatsoever - Follows identical patterns used by existing pspv1-pspv6 structures **Risk assessment: VERY LOW** - The driver already handles NULL `platform_access` - verified in `psp- dev.c`: ```c if (psp->vdata->platform_access) { ret = platform_access_dev_init(psp); ... } ``` - Several existing structures (pspv1, pspv4, pspv6) already omit `platform_access` - The `teev2` structure referenced already exists since v6.5 - All register offsets are identical to pspv5 ### 5. USER IMPACT **Who is affected:** - Users with AMD PCI device 0x115A (new AMD security processor variant) - Without this patch, this hardware is completely non-functional **Severity:** HIGH for affected users - enables critical security hardware (TPM-like functionality) ### 6. STABILITY INDICATORS **Positive signals:** - Acked by Tom Lendacky (the original driver author and AMD maintainer) - Follows exact same pattern as 10+ previous device ID additions in this driver - Same author (Mario Limonciello) has successfully added similar devices before (0x17E0, 0x156E, etc.) ### 7. DEPENDENCY CHECK **Required in stable tree:** - `teev2` structure - added in v6.5 (commit 4aa0931be8f0a) - Verified present in v6.6 and later **Recent related commits:** - 52e8ae868a824: "Add missing bootloader info reg for pspv5" (May 2025) - 72942d6538564: "Add missing tee info reg for teev2" (May 2025) The pspv7 structure in this commit already includes the `bootloader_info_reg` correctly, so it was created after these fixes. ### 8. COMPARISON WITH SIMILAR COMMITS This commit follows the exact same pattern as: - `bb4185e595e47`: "Add support for PCI device 0x156E" - Added pspv6 + dev_vdata[8] + PCI ID - `4aa0931be8f0a`: "Add support for PCI device 0x17E0" - Added pspv5/teev2 + dev_vdata[7] + PCI ID - `6cb345939b8cc`: "Add support for PCI device 0x1134" - Added PCI ID only - `63935e2ee1f2a`: "Add support for PCI device 0x17D8" - Added PCI ID only These similar device ID additions are routinely considered for stable trees. --- ## Final Assessment **Should this be backported?** **YES**, for the following reasons: 1. **Falls under the NEW DEVICE ID exception** - explicitly allowed per stable kernel rules for enabling real hardware 2. **Trivial, data-only change** - ~17 lines, no logic changes 3. **Uses existing, proven infrastructure** - teev2 exists, NULL platform_access handling exists 4. **Follows established patterns** - identical to 10+ previous similar commits in this driver 5. **Zero risk of regression** - only affects users with the specific 0x115A device 6. **Enables real hardware** - without this, users with this AMD security processor cannot use it at all 7. **Properly reviewed** - Acked by AMD maintainer, merged by crypto subsystem maintainer **Concerns:** - Requires stable tree to have v6.6+ (for teev2 structure) - May need the bootloader_info_reg fixes backported first for consistency (commits 52e8ae868a824 and 72942d6538564) The change is obviously correct, well-tested (used same patterns as existing code), and enables hardware support that users need. This is exactly the type of device ID addition that stable trees accept. **YES** drivers/crypto/ccp/sp-pci.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c index e7bb803912a6d..8891ceee1d7d0 100644 --- a/drivers/crypto/ccp/sp-pci.c +++ b/drivers/crypto/ccp/sp-pci.c @@ -459,6 +459,17 @@ static const struct psp_vdata pspv6 = { .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ }; +static const struct psp_vdata pspv7 = { + .tee = &teev2, + .cmdresp_reg = 0x10944, /* C2PMSG_17 */ + .cmdbuff_addr_lo_reg = 0x10948, /* C2PMSG_18 */ + .cmdbuff_addr_hi_reg = 0x1094c, /* C2PMSG_19 */ + .bootloader_info_reg = 0x109ec, /* C2PMSG_59 */ + .feature_reg = 0x109fc, /* C2PMSG_63 */ + .inten_reg = 0x10510, /* P2CMSG_INTEN */ + .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ +}; + #endif static const struct sp_dev_vdata dev_vdata[] = { @@ -525,6 +536,13 @@ static const struct sp_dev_vdata dev_vdata[] = { .psp_vdata = &pspv6, #endif }, + { /* 9 */ + .bar = 2, +#ifdef CONFIG_CRYPTO_DEV_SP_PSP + .psp_vdata = &pspv7, +#endif + }, + }; static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&dev_vdata[0] }, @@ -539,6 +557,7 @@ static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x17E0), (kernel_ulong_t)&dev_vdata[7] }, { PCI_VDEVICE(AMD, 0x156E), (kernel_ulong_t)&dev_vdata[8] }, { PCI_VDEVICE(AMD, 0x17D8), (kernel_ulong_t)&dev_vdata[8] }, + { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, /* Last entry must be zero */ { 0, } }; -- 2.51.0

2 days, 5 hours

1
2
0 0

[PATCH] hwmon: (dell-smm): Fix off-by-one error in dell_smm_is_visible()

by Armin Wolf

The documentation states that on machines supporting only global fan mode control, the pwmX_enable attributes should only be created for the first fan channel (pwm1_enable, aka channel 0). Fix the off-by-one error caused by the fact that fan channels have a zero-based index. Cc: stable(a)vger.kernel.org Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/hwmon/dell-smm-hwmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 683baf361c4c..a34753fc2973 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -861,9 +861,9 @@ static umode_t dell_smm_is_visible(const void *drvdata, enum hwmon_sensor_types if (auto_fan) { /* * The setting affects all fans, so only create a - * single attribute. + * single attribute for the first fan channel. */ - if (channel != 1) + if (channel != 0) return 0; /* -- 2.39.5

2 days, 6 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror