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

[PATCH AUTOSEL 6.18-5.10] x86/ptrace: Always inline trivial accessors

by Sasha Levin

From: Peter Zijlstra <peterz(a)infradead.org> [ Upstream commit 1fe4002cf7f23d70c79bda429ca2a9423ebcfdfa ] A KASAN build bloats these single load/store helpers such that it fails to inline them: vmlinux.o: error: objtool: irqentry_exit+0x5e8: call to instruction_pointer_set() with UACCESS enabled Make sure the compiler isn't allowed to do stupid. Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://patch.msgid.link/20251031105435.GU4068168@noisy.programming.kicks-a… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Comprehensive Analysis: x86/ptrace: Always inline trivial accessors ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `x86/ptrace: Always inline trivial accessors` **Key points from the commit message:** - A **KASAN build** bloats these single load/store helpers such that they fail to inline - The result is an **objtool ERROR**: `vmlinux.o: error: objtool: irqentry_exit+0x5e8: call to instruction_pointer_set() with UACCESS enabled` - The commit ensures "the compiler isn't allowed to do stupid" **Author:** Peter Zijlstra (Intel) - a highly respected kernel developer and maintainer **Committer:** Ingo Molnar - x86 subsystem maintainer **Missing tags:** - No `Cc: stable(a)vger.kernel.org` tag - No `Fixes:` tag ### 2. CODE CHANGE ANALYSIS The diff changes 8 trivial accessor functions from `static inline` to `static __always_inline`: | Function | Purpose | Complexity | |----------|---------|------------| | `regs_return_value()` | Returns `regs->ax` | 1 line | | `regs_set_return_value()` | Sets `regs->ax = rc` | 1 line | | `kernel_stack_pointer()` | Returns `regs->sp` | 1 line | | `instruction_pointer()` | Returns `regs->ip` | 1 line | | `instruction_pointer_set()` | Sets `regs->ip = val` | 1 line | | `frame_pointer()` | Returns `regs->bp` | 1 line | | `user_stack_pointer()` | Returns `regs->sp` | 1 line | | `user_stack_pointer_set()` | Sets `regs->sp = val` | 1 line | **Technical mechanism of the bug:** 1. KASAN adds memory sanitization instrumentation to functions 2. Even trivial one-liner functions get bloated with KASAN checks 3. The compiler decides the bloated functions are "too big" to inline 4. These functions get called from `irqentry_exit()` in contexts where UACCESS is enabled (SMAP disabled via STAC) 5. Objtool validates that no unexpected function calls happen with UACCESS enabled (security/correctness requirement) 6. Result: **BUILD FAILURE** (error, not warning) **Why `__always_inline` fixes it:** ```c #define __always_inline inline __attribute__((__always_inline__)) ``` This compiler attribute forces inlining regardless of any optimization settings or instrumentation, ensuring these trivial accessors always become inline code rather than function calls. ### 3. CLASSIFICATION - **Category:** BUILD FIX - **Type:** Fixes compilation error with KASAN on x86 - **Not a feature:** Simply enforces behavior that was intended (functions should always inline) - **Not a quirk/device ID/DT:** N/A ### 4. SCOPE AND RISK ASSESSMENT **Scope:** - 1 file changed: `arch/x86/include/asm/ptrace.h` - 10 insertions, 10 deletions (only adding `__always_` prefix) - Changes are purely compile-time **Risk: VERY LOW** - Zero runtime functional change when compiler already inlines - Only forces the compiler to do what it was supposed to do - Same pattern already successfully applied to other functions in the same file: - `user_mode()` - already `__always_inline` - `v8086_mode()` - commit b008893b08dcc - `ip_within_syscall_gap()` - commit c6b01dace2cd7 - `regs_irqs_disabled()` - already `__always_inline` ### 5. USER IMPACT **Who is affected:** - Anyone building x86 kernels with `CONFIG_KASAN=y` - KASAN is used for memory debugging, commonly in development and CI systems - Enterprise distributions often enable KASAN in debug/test builds **Severity:** HIGH (build failure = kernel cannot be compiled) ### 6. STABILITY INDICATORS - **Reviewed-by:** None explicit, but committed through tip tree - **Tested-by:** None explicit, but the error message shows it was reproduced - **Author credibility:** Peter Zijlstra is a top kernel maintainer - **Committer credibility:** Ingo Molnar is the x86 maintainer ### 7. DEPENDENCY CHECK **Dependencies:** NONE - This is a standalone fix - Does not depend on any other commits - The affected code exists unchanged in all stable kernels (5.10, 5.15, 6.1, 6.6) **Backport applicability verified:** ``` v5.10: static inline void instruction_pointer_set(...) ✓ v5.15: static inline void instruction_pointer_set(...) ✓ v6.1: static inline void instruction_pointer_set(...) ✓ v6.6: static inline void instruction_pointer_set(...) ✓ ``` The patch should apply cleanly to all stable trees. ### 8. HISTORICAL CONTEXT Similar fixes have been applied to this same file and other kernel files: | Commit | Description | Pattern | |--------|-------------|---------| | c6b01dace2cd7 | x86: Always inline ip_within_syscall_gap() | Same | | b008893b08dcc | x86/ptrace: Always inline v8086_mode() | Same | | cb0ca08b326aa | kcov: mark in_softirq_really() as __always_inline | Same (backported to stable) | The KASAN + objtool UACCESS validation issue is a known pattern that has been addressed multiple times with `__always_inline`. ### SUMMARY **Strong YES signals:** - ✅ Fixes a build failure (compilation error, not warning) - ✅ Small, surgical fix with clear scope (only adds `__always_inline`) - ✅ Obviously correct - trivial accessors should always inline - ✅ Zero functional/runtime change - ✅ No dependencies, applies cleanly to all stable trees - ✅ Well-established fix pattern used elsewhere in kernel - ✅ Authored by highly trusted maintainer (Peter Zijlstra) - ✅ Committed through the proper channel (tip tree via Ingo Molnar) **Weak NO signals:** - ⚠️ No explicit `Cc: stable` tag - ⚠️ No `Fixes:` tag The absence of stable tags is not disqualifying for build fixes. The stable kernel rules explicitly state that "build fixes that prevent compilation" are acceptable. This is a clear-cut build fix that prevents KASAN-enabled x86 kernels from compiling. ### CONCLUSION This commit **should be backported** to stable kernel trees. It's a textbook example of a build fix: - Small, contained, obviously correct - Fixes a real build failure affecting KASAN users - Zero risk of regression (only forces intended behavior) - No dependencies, clean backport - Follows established patterns from similar successful fixes **YES** arch/x86/include/asm/ptrace.h | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h index 50f75467f73d0..b5dec859bc75a 100644 --- a/arch/x86/include/asm/ptrace.h +++ b/arch/x86/include/asm/ptrace.h @@ -187,12 +187,12 @@ convert_ip_to_linear(struct task_struct *child, struct pt_regs *regs); extern void send_sigtrap(struct pt_regs *regs, int error_code, int si_code); -static inline unsigned long regs_return_value(struct pt_regs *regs) +static __always_inline unsigned long regs_return_value(struct pt_regs *regs) { return regs->ax; } -static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc) +static __always_inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc) { regs->ax = rc; } @@ -277,34 +277,34 @@ static __always_inline bool ip_within_syscall_gap(struct pt_regs *regs) } #endif -static inline unsigned long kernel_stack_pointer(struct pt_regs *regs) +static __always_inline unsigned long kernel_stack_pointer(struct pt_regs *regs) { return regs->sp; } -static inline unsigned long instruction_pointer(struct pt_regs *regs) +static __always_inline unsigned long instruction_pointer(struct pt_regs *regs) { return regs->ip; } -static inline void instruction_pointer_set(struct pt_regs *regs, - unsigned long val) +static __always_inline +void instruction_pointer_set(struct pt_regs *regs, unsigned long val) { regs->ip = val; } -static inline unsigned long frame_pointer(struct pt_regs *regs) +static __always_inline unsigned long frame_pointer(struct pt_regs *regs) { return regs->bp; } -static inline unsigned long user_stack_pointer(struct pt_regs *regs) +static __always_inline unsigned long user_stack_pointer(struct pt_regs *regs) { return regs->sp; } -static inline void user_stack_pointer_set(struct pt_regs *regs, - unsigned long val) +static __always_inline +void user_stack_pointer_set(struct pt_regs *regs, unsigned long val) { regs->sp = val; } -- 2.51.0

6 days, 19 hours

1
0
0 0

[PATCH v2] spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing

by Mark Brown

The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. This is particularly likely to happen when there is missing or broken DT description for the flashes attached to the controller. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Dealing with this issue properly is complicated by the fact that we don't know if runtime PM is active so can't tell if it will disable the clocks or not. We can, however, sidestep the issue for the flash descriptions by moving their parsing to when we parse the controller properties which also save us doing a bunch of setup which can never be used so let's do that. Reported-by: Francesco Dolcini <francesco(a)dolcini.it> Closes: https://lore.kernel.org/r/20251201072844.GA6785@francesco-nb Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- Changes in v2: - Switch to moving the DT parsing earlier so we avoid triggering the clock referencing problems. - Link to v1: https://patch.msgid.link/20251202-spi-cadence-qspi-runtime-pm-imbalance-v1-… --- drivers/spi/spi-cadence-quadspi.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index af6d050da1c8..bdbeef05cd72 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1845,6 +1845,12 @@ static int cqspi_probe(struct platform_device *pdev) return -ENODEV; } + ret = cqspi_setup_flash(cqspi); + if (ret) { + dev_err(dev, "failed to setup flash parameters %d\n", ret); + return ret; + } + /* Obtain QSPI clock. */ cqspi->clk = devm_clk_get(dev, NULL); if (IS_ERR(cqspi->clk)) { @@ -1988,12 +1994,6 @@ static int cqspi_probe(struct platform_device *pdev) pm_runtime_get_noresume(dev); } - ret = cqspi_setup_flash(cqspi); - if (ret) { - dev_err(dev, "failed to setup flash parameters %d\n", ret); - goto probe_setup_failed; - } - host->num_chipselect = cqspi->num_chipselect; if (ddata && (ddata->quirks & CQSPI_SUPPORT_DEVICE_RESET)) --- base-commit: cebdea5fc60642a39a76c237257a7e6662336006 change-id: 20251202-spi-cadence-qspi-runtime-pm-imbalance-657740cf7eae Best regards, -- Mark Brown <broonie(a)kernel.org>

6 days, 20 hours

2
3
0 0

[PATCH v2] drm/nouveau/gsp: Allocate fwsec-sb at boot

by Lyude Paul

At the moment - the memory allocation for fwsec-sb is created as-needed and is released after being used. Typically this is at some point well after driver load, which can cause runtime suspend/resume to initially work on driver load but then later fail on a machine that has been running for long enough with sufficiently high enough memory pressure: kworker/7:1: page allocation failure: order:5, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 7 UID: 0 PID: 875159 Comm: kworker/7:1 Not tainted 6.17.8-300.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: SLIMBOOK Executive/Executive, BIOS N.1.10GRU06 02/02/2024 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 warn_alloc+0x163/0x190 ? __alloc_pages_direct_compact+0x1b3/0x220 __alloc_pages_slowpath.constprop.0+0x57a/0xb10 __alloc_frozen_pages_noprof+0x334/0x350 __alloc_pages_noprof+0xe/0x20 __dma_direct_alloc_pages.isra.0+0x1eb/0x330 dma_direct_alloc_pages+0x3c/0x190 dma_alloc_pages+0x29/0x130 nvkm_firmware_ctor+0x1ae/0x280 [nouveau] nvkm_falcon_fw_ctor+0x3e/0x60 [nouveau] nvkm_gsp_fwsec+0x10e/0x2c0 [nouveau] ? sysvec_apic_timer_interrupt+0xe/0x90 nvkm_gsp_fwsec_sb+0x27/0x70 [nouveau] tu102_gsp_fini+0x65/0x110 [nouveau] ? ktime_get+0x3c/0xf0 nvkm_subdev_fini+0x67/0xc0 [nouveau] nvkm_device_fini+0x94/0x140 [nouveau] nvkm_udevice_fini+0x50/0x70 [nouveau] nvkm_object_fini+0xb1/0x140 [nouveau] nvkm_object_fini+0x70/0x140 [nouveau] ? __pfx_pci_pm_runtime_suspend+0x10/0x10 nouveau_do_suspend+0xe4/0x170 [nouveau] nouveau_pmops_runtime_suspend+0x3e/0xb0 [nouveau] pci_pm_runtime_suspend+0x67/0x1a0 ? __pfx_pci_pm_runtime_suspend+0x10/0x10 __rpm_callback+0x45/0x1f0 ? __pfx_pci_pm_runtime_suspend+0x10/0x10 rpm_callback+0x6d/0x80 rpm_suspend+0xe5/0x5e0 ? finish_task_switch.isra.0+0x99/0x2c0 pm_runtime_work+0x98/0xb0 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xf9/0x240 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0xf1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> The reason this happens is because the fwsec-sb firmware image only supports being booted from a contiguous coherent sysmem allocation. If a system runs into enough memory fragmentation from memory pressure, such as what can happen on systems with low amounts of memory, this can lead to a situation where it later becomes impossible to find space for a large enough contiguous allocation to hold fwsec-sb. This causes us to fail to boot the firmware image, causing the GPU to fail booting and causing the driver to fail. Since this firmware can't use non-contiguous allocations, the best solution to avoid this issue is to simply allocate the memory for fwsec-sb during initial driver-load, and reuse the memory allocation when fwsec-sb needs to be used. We then release the memory allocations on driver unload. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 594766ca3e53 ("drm/nouveau/gsp: move booter handling to GPU-specific code") Cc: <stable(a)vger.kernel.org> # v6.16+ --- V2: * I realized we don't need to keep fwsec-frts allocated since we only use it at the start, just fwsec-sb. Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 4 ++ .../gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 61 +++++++++++++------ .../gpu/drm/nouveau/nvkm/subdev/gsp/priv.h | 3 + .../drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 10 ++- 4 files changed, 58 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h index 226c7ec56b8ed..b8b97e10ae83e 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h @@ -73,6 +73,10 @@ struct nvkm_gsp { const struct firmware *bl; const struct firmware *rm; + + struct { + struct nvkm_falcon_fw sb; + } falcon; } fws; struct nvkm_firmware fw; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c index 5b721bd9d7994..5037602466604 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c @@ -259,18 +259,16 @@ nvkm_gsp_fwsec_v3(struct nvkm_gsp *gsp, const char *name, } static int -nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) +nvkm_gsp_fwsec_init(struct nvkm_gsp *gsp, struct nvkm_falcon_fw *fw, const char *name, u32 init_cmd) { struct nvkm_subdev *subdev = &gsp->subdev; struct nvkm_device *device = subdev->device; struct nvkm_bios *bios = device->bios; const union nvfw_falcon_ucode_desc *desc; struct nvbios_pmuE flcn_ucode; - u8 idx, ver, hdr; u32 data; u16 size, vers; - struct nvkm_falcon_fw fw = {}; - u32 mbox0 = 0; + u8 idx, ver, hdr; int ret; /* Lookup in VBIOS. */ @@ -291,8 +289,8 @@ nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) vers = (desc->v2.Hdr & 0x0000ff00) >> 8; switch (vers) { - case 2: ret = nvkm_gsp_fwsec_v2(gsp, name, &desc->v2, size, init_cmd, &fw); break; - case 3: ret = nvkm_gsp_fwsec_v3(gsp, name, &desc->v3, size, init_cmd, &fw); break; + case 2: ret = nvkm_gsp_fwsec_v2(gsp, name, &desc->v2, size, init_cmd, fw); break; + case 3: ret = nvkm_gsp_fwsec_v3(gsp, name, &desc->v3, size, init_cmd, fw); break; default: nvkm_error(subdev, "%s(v%d): version unknown\n", name, vers); return -EINVAL; @@ -303,15 +301,19 @@ nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) return ret; } - /* Boot. */ - ret = nvkm_falcon_fw_boot(&fw, subdev, true, &mbox0, NULL, 0, 0); - nvkm_falcon_fw_dtor(&fw); - if (ret) - return ret; - return 0; } +static int +nvkm_gsp_fwsec_boot(struct nvkm_gsp *gsp, struct nvkm_falcon_fw *fw) +{ + struct nvkm_subdev *subdev = &gsp->subdev; + u32 mbox0 = 0; + + /* Boot */ + return nvkm_falcon_fw_boot(fw, subdev, true, &mbox0, NULL, 0, 0); +} + int nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) { @@ -320,7 +322,7 @@ nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) int ret; u32 err; - ret = nvkm_gsp_fwsec(gsp, "fwsec-sb", NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB); + ret = nvkm_gsp_fwsec_boot(gsp, &gsp->fws.falcon.sb); if (ret) return ret; @@ -334,27 +336,48 @@ nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) return 0; } +int +nvkm_gsp_fwsec_sb_ctor(struct nvkm_gsp *gsp) +{ + return nvkm_gsp_fwsec_init(gsp, &gsp->fws.falcon.sb, "fwsec-sb", + NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB); +} + +void +nvkm_gsp_fwsec_sb_dtor(struct nvkm_gsp *gsp) +{ + nvkm_falcon_fw_dtor(&gsp->fws.falcon.sb); +} + int nvkm_gsp_fwsec_frts(struct nvkm_gsp *gsp) { struct nvkm_subdev *subdev = &gsp->subdev; struct nvkm_device *device = subdev->device; + struct nvkm_falcon_fw fw = {}; int ret; u32 err, wpr2_lo, wpr2_hi; - ret = nvkm_gsp_fwsec(gsp, "fwsec-frts", NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS); + ret = nvkm_gsp_fwsec_init(gsp, &fw, "fwsec-frts", NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS); if (ret) return ret; + ret = nvkm_gsp_fwsec_boot(gsp, &fw); + if (ret) + goto fwsec_dtor; + /* Verify. */ err = nvkm_rd32(device, 0x001400 + (0xe * 4)) >> 16; if (err) { nvkm_error(subdev, "fwsec-frts: 0x%04x\n", err); - return -EIO; + ret = -EIO; + } else { + wpr2_lo = nvkm_rd32(device, 0x1fa824); + wpr2_hi = nvkm_rd32(device, 0x1fa828); + nvkm_debug(subdev, "fwsec-frts: WPR2 @ %08x - %08x\n", wpr2_lo, wpr2_hi); } - wpr2_lo = nvkm_rd32(device, 0x1fa824); - wpr2_hi = nvkm_rd32(device, 0x1fa828); - nvkm_debug(subdev, "fwsec-frts: WPR2 @ %08x - %08x\n", wpr2_lo, wpr2_hi); - return 0; +fwsec_dtor: + nvkm_falcon_fw_dtor(&fw); + return ret; } diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h index c3494b7ac572b..86bdd203bc107 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h @@ -6,7 +6,10 @@ enum nvkm_acr_lsf_id; int nvkm_gsp_fwsec_frts(struct nvkm_gsp *); + +int nvkm_gsp_fwsec_sb_ctor(struct nvkm_gsp *); int nvkm_gsp_fwsec_sb(struct nvkm_gsp *); +void nvkm_gsp_fwsec_sb_dtor(struct nvkm_gsp *); struct nvkm_gsp_fwif { int version; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c index 32e6a065d6d7a..2a7e80c6d70f3 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c @@ -1817,12 +1817,16 @@ r535_gsp_rm_boot_ctor(struct nvkm_gsp *gsp) RM_RISCV_UCODE_DESC *desc; int ret; + ret = nvkm_gsp_fwsec_sb_ctor(gsp); + if (ret) + return ret; + hdr = nvfw_bin_hdr(&gsp->subdev, fw->data); desc = (void *)fw->data + hdr->header_offset; ret = nvkm_gsp_mem_ctor(gsp, hdr->data_size, &gsp->boot.fw); if (ret) - return ret; + goto dtor_fwsec; memcpy(gsp->boot.fw.data, fw->data + hdr->data_offset, hdr->data_size); @@ -1831,6 +1835,9 @@ r535_gsp_rm_boot_ctor(struct nvkm_gsp *gsp) gsp->boot.manifest_offset = desc->manifestOffset; gsp->boot.app_version = desc->appVersion; return 0; +dtor_fwsec: + nvkm_gsp_fwsec_sb_dtor(gsp); + return ret; } static const struct nvkm_firmware_func @@ -2101,6 +2108,7 @@ r535_gsp_dtor(struct nvkm_gsp *gsp) mutex_destroy(&gsp->cmdq.mutex); nvkm_gsp_dtor_fws(gsp); + nvkm_gsp_fwsec_sb_dtor(gsp); nvkm_gsp_mem_dtor(&gsp->rmargs); nvkm_gsp_mem_dtor(&gsp->wpr_meta); base-commit: 62433efe0b06042d8016ba0713d801165a939229 -- 2.52.0

6 days, 21 hours

2
1
0 0

+ kasan-unpoison-vms-addresses-with-a-common-tag.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kasan: unpoison vms[area] addresses with a common tag has been added to the -mm mm-hotfixes-unstable branch. Its filename is kasan-unpoison-vms-addresses-with-a-common-tag.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Subject: kasan: unpoison vms[area] addresses with a common tag Date: Thu, 04 Dec 2025 19:00:11 +0000 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. Use the new vmalloc flag that disables random tag assignment in __kasan_unpoison_vmalloc() - pass the same random tag to all the vm_structs by tagging the pointers before they go inside __kasan_unpoison_vmalloc(). Assigning a common tag resolves the pcpu chunk address mismatch. Link: https://lkml.kernel.org/r/873821114a9f722ffb5d6702b94782e902883fdf.17648745… Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Jiayuan Chen <jiayuan.chen(a)linux.dev> Cc: Kees Cook <kees(a)kernel.org> Cc: Marco Elver <elver(a)google.com> Cc: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> [6.1+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/common.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) --- a/mm/kasan/common.c~kasan-unpoison-vms-addresses-with-a-common-tag +++ a/mm/kasan/common.c @@ -591,11 +591,28 @@ void __kasan_unpoison_vmap_areas(struct unsigned long size; void *addr; int area; + u8 tag; - for (area = 0 ; area < nr_vms ; area++) { + /* + * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers + * would be unpoisoned with the KASAN_TAG_KERNEL which would disable + * KASAN checks down the line. + */ + if (flags & KASAN_VMALLOC_KEEP_TAG) { + pr_warn("KASAN_VMALLOC_KEEP_TAG flag shouldn't be already set!\n"); + return; + } + + size = vms[0]->size; + addr = vms[0]->addr; + vms[0]->addr = __kasan_unpoison_vmalloc(addr, size, flags); + tag = get_tag(vms[0]->addr); + + for (area = 1 ; area < nr_vms ; area++) { size = vms[area]->size; - addr = vms[area]->addr; - vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags); + addr = set_tag(vms[area]->addr, tag); + vms[area]->addr = + __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG); } } #endif _ Patches currently in -mm which might be from maciej.wieczor-retman(a)intel.com are kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch kasan-unpoison-vms-addresses-with-a-common-tag.patch

6 days, 22 hours

1
0
0 0

+ kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kasan: refactor pcpu kasan vmalloc unpoison has been added to the -mm mm-hotfixes-unstable branch. Its filename is kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Subject: kasan: refactor pcpu kasan vmalloc unpoison Date: Thu, 04 Dec 2025 19:00:04 +0000 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. Link: https://lkml.kernel.org/r/eb61d93b907e262eefcaa130261a08bcb6c5ce51.17648745… Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Jiayuan Chen <jiayuan.chen(a)linux.dev> Cc: Kees Cook <kees(a)kernel.org> Cc: Marco Elver <elver(a)google.com> Cc: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> [6.1+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kasan.h | 15 +++++++++++++++ mm/kasan/common.c | 17 +++++++++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 33 insertions(+), 3 deletions(-) --- a/include/linux/kasan.h~kasan-refactor-pcpu-kasan-vmalloc-unpoison +++ a/include/linux/kasan.h @@ -615,6 +615,16 @@ static __always_inline void kasan_poison __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_vmall 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)) && \ --- a/mm/kasan/common.c~kasan-refactor-pcpu-kasan-vmalloc-unpoison +++ a/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 *addr } 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 --- a/mm/vmalloc.c~kasan-refactor-pcpu-kasan-vmalloc-unpoison +++ a/mm/vmalloc.c @@ -4872,9 +4872,7 @@ retry: * 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; _ Patches currently in -mm which might be from maciej.wieczor-retman(a)intel.com are kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch kasan-unpoison-vms-addresses-with-a-common-tag.patch

6 days, 22 hours

1
0
0 0

+ mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Jiayuan Chen <jiayuan.chen(a)linux.dev> Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN Date: Thu, 04 Dec 2025 18:59:55 +0000 Patch series "kasan: vmalloc: Fixes for the percpu allocator and vrealloc", v3. Patches fix two issues related to KASAN and vmalloc. The first one, a KASAN tag mismatch, possibly resulting in a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. Initially it was only noticed on x86 [1] but later a similar issue was also reported on arm64 [2]. Specifically the problem is related to how vm_structs interact with pcpu_chunks - both when they are allocated, assigned and when pcpu_chunk addresses are derived. When vm_structs are allocated they are unpoisoned, each with a different random tag, if vmalloc support is enabled along the KASAN mode. Later when first pcpu chunk is allocated it gets its 'base_addr' field set to the first allocated vm_struct. With that it inherits that vm_struct's tag. When pcpu_chunk addresses are later derived (by pcpu_chunk_addr(), for example in pcpu_alloc_noprof()) the base_addr field is used and offsets are added to it. If the initial conditions are satisfied then some of the offsets will point into memory allocated with a different vm_struct. So while the lower bits will get accurately derived the tag bits in the top of the pointer won't match the shadow memory contents. The solution (proposed at v2 of the x86 KASAN series [3]) is to unpoison the vm_structs with the same tag when allocating them for the per cpu allocator (in pcpu_get_vm_areas()). The second one reported by syzkaller [4] is related to vrealloc and happens because of random tag generation when unpoisoning memory without allocating new pages. This breaks shadow memory tracking and needs to reuse the existing tag instead of generating a new one. At the same time an inconsistency in used flags is corrected. This patch (of 3): Syzkaller reported a memory out-of-bounds bug [4]. This patch fixes two issues: 1. In vrealloc the KASAN_VMALLOC_VM_ALLOC flag is missing when unpoisoning the extended region. This flag is required to correctly associate the allocation with KASAN's vmalloc tracking. Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it. vrealloc must behave consistently -- especially when reusing existing vmalloc regions -- to ensure KASAN can track allocations correctly. 2. When vrealloc reuses an existing vmalloc region (without allocating new pages) KASAN generates a new tag, which breaks tag-based memory access tracking. Introduce KASAN_VMALLOC_KEEP_TAG, a new KASAN flag that allows reusing the tag already attached to the pointer, ensuring consistent tag behavior during reallocation. Pass KASAN_VMALLOC_KEEP_TAG and KASAN_VMALLOC_VM_ALLOC to the kasan_unpoison_vmalloc inside vrealloc_node_align_noprof(). Link: https://lkml.kernel.org/r/38dece0a4074c43e48150d1e242f8242c73bf1a5.17648745… Link: https://lore.kernel.org/all/e7e04692866d02e6d3b32bb43b998e5d17092ba4.173868… [1] Link: https://lore.kernel.org/all/aMUrW1Znp1GEj7St@MiWiFi-R3L-srv/ [2] Link: https://lore.kernel.org/all/CAPAsAGxDRv_uFeMYu9TwhBVWHCCtkSxoWY4xmFB_vowMbi… [3] Link: https://syzkaller.appspot.com/bug?extid=3D997752115a851cb0cf36 [4] Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Co-developed-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing" ) Reported-by: syzbot+997752115a851cb0cf36(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/ Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Marco Elver <elver(a)google.com> Cc: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kasan.h | 1 + mm/kasan/hw_tags.c | 2 +- mm/kasan/shadow.c | 4 +++- mm/vmalloc.c | 4 +++- 4 files changed, 8 insertions(+), 3 deletions(-) --- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/include/linux/kasan.h @@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vma #define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u) #define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u) #define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) +#define KASAN_VMALLOC_KEEP_TAG ((__force kasan_vmalloc_flags_t)0x08u) #define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */ #define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ --- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/hw_tags.c @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi return (void *)start; } - tag = kasan_random_tag(); + tag = (flags & KASAN_VMALLOC_KEEP_TAG) ? get_tag(start) : kasan_random_tag(); start = set_tag(start, tag); /* Unpoison and initialize memory up to size. */ --- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/shadow.c @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi !(flags & KASAN_VMALLOC_PROT_NORMAL)) return (void *)start; - start = set_tag(start, kasan_random_tag()); + if (unlikely(!(flags & KASAN_VMALLOC_KEEP_TAG))) + start = set_tag(start, kasan_random_tag()); + kasan_unpoison(start, size, false); return (void *)start; } --- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/vmalloc.c @@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const v */ if (size <= alloced_size) { kasan_unpoison_vmalloc(p + old_size, size - old_size, - KASAN_VMALLOC_PROT_NORMAL); + KASAN_VMALLOC_PROT_NORMAL | + KASAN_VMALLOC_VM_ALLOC | + KASAN_VMALLOC_KEEP_TAG); /* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during _ Patches currently in -mm which might be from jiayuan.chen(a)linux.dev are mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch

6 days, 22 hours

1
0
0 0

+ revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb" has been added to the -mm mm-hotfixes-unstable branch. Its filename is revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Shuah Khan <skhan(a)linuxfoundation.org> Subject: Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb" Date: Wed, 3 Dec 2025 19:33:56 -0700 This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98. Enabling HAVE_GIGANTIC_FOLIOS broke kernel build and git clone on two systems. git fetch-pack fails when cloning large repos and make hangs or errors out of Makefile.build with Error: 139. These failures are random with git clone failing after fetching 1% of the objects, and make hangs while compiling random files. Below is is one of the git clone failures: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_6.19 Cloning into 'linux_6.19'... remote: Enumerating objects: 11173575, done. remote: Counting objects: 100% (785/785), done. remote: Compressing objects: 100% (373/373), done. remote: Total 11173575 (delta 534), reused 505 (delta 411), pack-reused 11172790 (from 1) Receiving objects: 100% (11173575/11173575), 3.00 GiB | 7.08 MiB/s, done. Resolving deltas: 100% (9195212/9195212), done. fatal: did not receive expected object 0002003e951b5057c16de5a39140abcbf6e44e50 fatal: fetch-pack: invalid index-pack output (akpm: reverting this probably just hides a bug, but let's do that for now while the bug is being worked on). Link: https://lkml.kernel.org/r/20251204023358.54107-1-skhan@linuxfoundation.org Fixes: 39231e8d6ba7 ("mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb") Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Cc: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Madhavan Srinivasan <maddy(a)linux.ibm.com> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Linus Torvalds <torvalds(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/powerpc/Kconfig | 1 - arch/powerpc/platforms/Kconfig.cputype | 1 + include/linux/mm.h | 13 +++---------- mm/Kconfig | 7 ------- 4 files changed, 4 insertions(+), 18 deletions(-) --- a/arch/powerpc/Kconfig~revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb +++ a/arch/powerpc/Kconfig @@ -137,7 +137,6 @@ config PPC select ARCH_HAS_DMA_OPS if PPC64 select ARCH_HAS_FORTIFY_SOURCE select ARCH_HAS_GCOV_PROFILE_ALL - select ARCH_HAS_GIGANTIC_PAGE if ARCH_SUPPORTS_HUGETLBFS select ARCH_HAS_KCOV select ARCH_HAS_KERNEL_FPU_SUPPORT if PPC64 && PPC_FPU select ARCH_HAS_MEMBARRIER_CALLBACKS --- a/arch/powerpc/platforms/Kconfig.cputype~revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb +++ a/arch/powerpc/platforms/Kconfig.cputype @@ -423,6 +423,7 @@ config PPC_64S_HASH_MMU config PPC_RADIX_MMU bool "Radix MMU Support" depends on PPC_BOOK3S_64 + select ARCH_HAS_GIGANTIC_PAGE default y help Enable support for the Power ISA 3.0 Radix style MMU. Currently this --- a/include/linux/mm.h~revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb +++ a/include/linux/mm.h @@ -2074,7 +2074,7 @@ static inline unsigned long folio_nr_pag return folio_large_nr_pages(folio); } -#if !defined(CONFIG_HAVE_GIGANTIC_FOLIOS) +#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) /* * We don't expect any folios that exceed buddy sizes (and consequently * memory sections). @@ -2087,17 +2087,10 @@ static inline unsigned long folio_nr_pag * pages are guaranteed to be contiguous. */ #define MAX_FOLIO_ORDER PFN_SECTION_SHIFT -#elif defined(CONFIG_HUGETLB_PAGE) -/* - * There is no real limit on the folio size. We limit them to the maximum we - * currently expect (see CONFIG_HAVE_GIGANTIC_FOLIOS): with hugetlb, we expect - * no folios larger than 16 GiB on 64bit and 1 GiB on 32bit. - */ -#define MAX_FOLIO_ORDER get_order(IS_ENABLED(CONFIG_64BIT) ? SZ_16G : SZ_1G) #else /* - * Without hugetlb, gigantic folios that are bigger than a single PUD are - * currently impossible. + * There is no real limit on the folio size. We limit them to the maximum we + * currently expect (e.g., hugetlb, dax). */ #define MAX_FOLIO_ORDER PUD_ORDER #endif --- a/mm/Kconfig~revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb +++ a/mm/Kconfig @@ -908,13 +908,6 @@ config PAGE_MAPCOUNT config PGTABLE_HAS_HUGE_LEAVES def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE -# -# We can end up creating gigantic folio. -# -config HAVE_GIGANTIC_FOLIOS - def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ - (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) - # TODO: Allow to be enabled without THP config ARCH_SUPPORTS_HUGE_PFNMAP def_bool n _ Patches currently in -mm which might be from skhan(a)linuxfoundation.org are revert-mm-fix-max_folio_order-on-powerpc-configs-with-hugetlb.patch

6 days, 22 hours

1
0
0 0

[PATCH v1 3/3] io_uring/rsrc: fix lost entries after cloned range

by Joanne Koong

When cloning with node replacements (IORING_REGISTER_DST_REPLACE), destination entries after the cloned range are not copied over. Add logic to copy them over to the new destination table. Fixes: c1329532d5aa ("io_uring/rsrc: allow cloning with node replacements") Cc: stable(a)vger.kernel.org Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> --- io_uring/rsrc.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c index 04f56212398a..a63474b331bf 100644 --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -1205,7 +1205,7 @@ static int io_clone_buffers(struct io_ring_ctx *ctx, struct io_ring_ctx *src_ctx if (ret) return ret; - /* Fill entries in data from dst that won't overlap with src */ + /* Copy original dst nodes from before the cloned range */ for (i = 0; i < min(arg->dst_off, ctx->buf_table.nr); i++) { struct io_rsrc_node *node = ctx->buf_table.nodes[i]; @@ -1238,6 +1238,16 @@ static int io_clone_buffers(struct io_ring_ctx *ctx, struct io_ring_ctx *src_ctx i++; } + /* Copy original dst nodes from after the cloned range */ + for (i = nbufs; i < ctx->buf_table.nr; i++) { + struct io_rsrc_node *node = ctx->buf_table.nodes[i]; + + if (node) { + data.nodes[i] = node; + node->refs++; + } + } + /* * If asked for replace, put the old table. data->nodes[] holds both * old and new nodes at this point. -- 2.47.3

6 days, 22 hours

1
0
0 0

[PATCH 5.15.y RESEND] KVM: arm64: sys_regs: disable -Wuninitialized-const-pointer warning

by Justin Stitt

A new warning in Clang 22 [1] complains that @clidr passed to get_clidr_el1() is an uninitialized const pointer. get_clidr_el1() doesn't really care since it casts away the const-ness anyways -- it is a false positive. | ../arch/arm64/kvm/sys_regs.c:2838:23: warning: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer] | 2838 | get_clidr_el1(NULL, &clidr); /* Ugly... */ | | ^~~~~ This patch isn't needed for anything past 6.1 as this code section was reworked in Commit 7af0c2534f4c ("KVM: arm64: Normalize cache configuration"). Since there is no upstream equivalent, this patch just needs to be applied to 5.15. Disable this warning for sys_regs.o with an iron fist as it doesn't make sense to waste maintainer's time or potentially break builds by backporting large changelists from 6.2+. Cc: stable(a)vger.kernel.org Fixes: 7c8c5e6a9101e ("arm64: KVM: system register handling") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d44… [1] Reviewed-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Justin Stitt <justinstitt(a)google.com> --- Resending this with Nathan's RB tag, an updated commit log and better recipients from checkpatch.pl. I'm also sending a similar patch resend for 6.1. --- arch/arm64/kvm/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile index 989bb5dad2c8..109cca425d3e 100644 --- a/arch/arm64/kvm/Makefile +++ b/arch/arm64/kvm/Makefile @@ -25,3 +25,6 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \ vgic/vgic-its.o vgic/vgic-debug.o kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o + +# Work around a false positive Clang 22 -Wuninitialized-const-pointer warning +CFLAGS_sys_regs.o := $(call cc-disable-warning, uninitialized-const-pointer) --- base-commit: 8bb7eca972ad531c9b149c0a51ab43a417385813 change-id: 20250728-b4-stable-disable-uninit-ptr-warn-5-15-c0c9db3df206 Best regards, -- Justin Stitt <justinstitt(a)google.com>

6 days, 23 hours

1
0
0 0

Optimiza tu reclutamiento con PsicoSmart

by Valeria Pérez

Mejora tus contrataciones con PsicoSmart body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Evalúa talento de forma objetiva y mejora tus contrataciones con PsicoSmart. Hola, , ¿Te ha pasado que un candidato luce perfecto en entrevista, pero en el trabajo no encaja como esperabas? En selección, confiar solo en la percepción puede llevar a decisiones costosas. Por eso quiero presentarte PsicoSmart, una herramienta creada para que los equipos de Recursos Humanos tomen decisiones más objetivas y acertadas. Con PsicoSmart puedes: Aplicar 31 pruebas psicométricas que evalúan liderazgo, honestidad, comunicación e inteligencia. Validar conocimientos técnicos con más de 2,500 exámenes especializados. Supervisar la identidad de quien responde mediante captura fotográfica automática durante la evaluación. Gestionar todo desde una sola plataforma, accesible desde cualquier dispositivo. Si estás buscando mejorar tus contrataciones, podría ser una muy buena opción. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqruseup">click aquí</a>

1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror