Repository navigation
Rebase edera/mainline onto master @ 72a16bcff25e - #45
Closed
edera-rebase-app[bot] wants to merge 1752 commits into
Closed
edera-rebase-app[bot] wants to merge 1752 commits into
edera-rebase-app[bot] wants to merge 1752 commits into
Conversation
The BBML2 no-abort capability is an allow-list of CPUs that support BBML2 and do not raise TLB conflict aborts for mapping granularity changes. Add the NVIDIA Rigel core to that allow-list. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
…us', 'for-next/preemptible-this-cpu', 'for-next/cpu-errata', 'for-next/mpam', 'for-next/kselftest', 'for-next/efi', 'for-next/secondary-boot-prep', 'for-next/sysreg' and 'for-next/gcs', remote-tracking branch 'arm64/for-next/perf' into for-next/core
* arm64/for-next/perf: (22 commits)
drivers/perf: apple_m1: Add macOS 27 M2 Event
perf/marvell: cn10k_tad: Publish the OF module alias
perf: xgene: initialize lock before requesting IRQ
perf: marvell: avoid large stack variables
perf/dwc_pcie: Fix PCI device reference leak in probe
coresight: perf: Suppress ITRACE start records
perf: arm_spe: Suppress redundant ITRACE start records
perf/core: Export perf_event_itrace_started()
perf/cxl: Clear stale overflow status before using a counter
perf/cxl: Don't log through pmu.dev in the overflow interrupt handler
perf/cxl: Validate the hardware-reported counter width
perf/cxl: Unfreeze counters after handling an overflow interrupt
perf/cxl: Don't share the overflow interrupt, and keep it pinned
cxl/pci: Add the PMUs after configuring events
perf/cxl: Split the MSI vector out of info->irq
perf/cxl: Accept an overflow interrupt on MSI message number 0
perf/cxl: Fix the counter overflow delta fixup
perf/cxl: Clear stale event fields before reprogramming a counter
perf/cxl: Program the requested event group on configurable counters
drivers/perf: hisi: Add cycle event for new MN PMU
...
* for-next/misc:
arm64: cpufeature: Enable BBML2 for NVIDIA Rigel
arm64: cputype: Add NVIDIA Rigel definitions
arm64: raise default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VA
arm64/debug: mask debug exceptions when called from common code
arm64: clear_page[s] using memset
arm64/sve: Don't zero the SVE state buffer when the SVE state is live
arm64/cpufeature: Drop redundant define(ID_AA64MMFR0..._SUPPORTED_LPA2)
arm64: Use proper include variant
arm64: include: fix repeated word 'to' in comment
selftests: arm64: fix typo "hander" in comment
arm64: fix typos in comments
docs: arm64: Fix typo "initalised" in booting.rst
arm64: alternative: Remove 'cfg' parameter
arm64: mte-kasan: Use IS_ENABLED() rather than ALTERNATIVE() 'cfg' parameter
arm64/cpufeature: Change description for ARM64_HAS_LPA2
* for-next/be-gone:
drivers: Kconfig: Simplify dependencies on ARM64 && !CPU_BIG_ENDIAN
arm64: Kbuild: Remove vestigial big-endian support
gve: Add explicit ARM64 dependency to Kconfig
crypto: hisilicon/sec2: Remove check of CONFIG_CPU_LITTLE_ENDIAN
arm64: Remove all usage of __AARCH64EB__
arm64: Remove all usage of CONFIG_CPU_BIG_ENDIAN
KVM: arm64: Remove support for a big-endian hypervisor object
arm64: vdso32: Always build compat vDSO object as little-endian
arm64: assembler: Remove endianness helper macros
arm64: lib: Assume a little-endian kernel in optimised string routines
arm64: lib: Assume a little-endian kernel in custom library routines
arm64: crypto: Assume a little-endian kernel
arm64: bpf: Remove big-endian support from the JIT compiler
selftests/arm64: Remove big-endian support
* for-next/smccc-bus:
: Switch Arm SMCCC firmware services to an SMCCC bus
arm64: rsi: Correct type of realm_config::hash_algo
firmware: smccc: Pass only the required device probe arguments
firmware: arm_rmm: Add SPDX and sort the Kconfig and Makefile entries
coco: guest: arm64: Remove dummy CCA platform device
coco: guest: arm64: Add sysfs ABI for CCA Realm guests
firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
virt: coco: arm-cca-guest: Rename TSM report source file
arm64: realm: Move Realm memory encryption ops to RSI code
firmware: arm_rmm: Move RSI support out of arch/arm64
firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
firmware: smccc: Add an Arm SMCCC bus
* for-next/preemptible-this-cpu:
: Preemptible this_cpu_*() operations
arm64: percpu: Remove _pcp_protect*() wrappers
arm64: percpu: Implement preemptible CMPXCHG128 ops
arm64: percpu: Implement preemptible CMPXCHG ops
arm64: percpu: Implement preemptible XCHG ops
arm64: percpu: Implement preemptible return RMW ops
arm64: percpu: Implement preemptible void RMW ops
arm64: percpu: Implement preemptible read/write ops
arm64: percpu: Add infrastructure for preemptible this_cpu_*() ops
arm64: entry: sdei: Make 'tsk' available
arm64: entry: sdei: Restore all clobberable GPRs
arm64: gpr-num: add __GPR_NUM() helper
arm64: gpr-num: Add wxN aliases for wN registers
arm64: percpu: Factor out percpu offset asm
arm64: ptrace: Always inline pt_regs_{read,write}_reg()
arm64: preempt: Treat should_resched() as unlikely
arm64: preempt: Simplify and optimize __preempt_count_dec_and_test()
arm64: cmpxchg128: LSE: Remove redundant operands
arm64: cmpxchg: LL/SC: Avoid redundant extension
* for-next/cpu-errata:
: Various CPU errata workarounds
arm64: errata: Add NXP i.MX8QM/8QP workaround for A53 cache coherency issue
arm64: cpufeature: Add ARM64_CPUCAP_SOC_ERRATUM for SoC-level errata
* for-next/mpam: (30 commits)
: MPAM updates
arm_mpam: make the mon_sel guard conditional only
arm_mpam: On saving mbwu state read the monitors before clearing CFG_MBWU_CTL
arm_mpam: detect and enable MPAM-Fb PCC support
arm_mpam: change MPAM-Fb error IRQ to use a threaded IRQ handler
arm_mpam: add MPAM-Fb MSC firmware access support
arm_mpam: prepare mon_sel locking for MPAM-Fb
arm_mpam: propagate MSC access errors in mpam_reset_class_locked()
arm_mpam: propagate MSC access errors for interrupt control
arm_mpam: propagate MSC access errors for mpam_reprogram_ris_partid()
arm_mpam: propagate MSC access errors for state saving function
arm_mpam: propagate MSC access errors for __ris_msmon_read()
arm_mpam: propagate MSC access errors for msmon helpers
arm_mpam: propagate MSC access errors for MBWU counters
arm_mpam: propagate MSC access errors for hw_probe functions
arm_mpam: let low level MSC accessors return an error
MAINTAINERS: Use linux-arm-kernel list for the MPAM driver
MAINTAINERS: Add mpam.rst to the MPAM DRIVER entry
arm_mpam: resctrl: Don't stop early when tearing down a class
arm_mpam: Switch to kvzmalloc_objs() for allocation of component cfg
arm_mpam: Don't loop forever if there is the maximum possible amount of PARTIDs
...
* for-next/kselftest:
: arm64 kselftest updates
kselftest/arm64: signal: copy each test binary only once
kselftest/arm64/mte: Use MTE safe memory accessors
kselftest/arm64/mte: Introduce MTE safe memory accessors
kselftest/arm64: Extend gcs-locking to cover cases where enable is unlocked
* for-next/efi:
: arm64 EFI updates/fixes
arm64/mm: Treat faults taken by EFI runtime firmware as kernel faults
arm64/efi: Clear PTE_WRITE when applying EFI_MEMORY_RO
* for-next/secondary-boot-prep:
: cpuinfo cleanup in preparation for parallel secondary bring-up
arm64: smp: Defer RCU registration during secondary CPU bringup
arm64: smp: Don't bother printing the I-cache policy for each CPU
arm64: smp: Defer update of secondary CPU capabilities
arm64: smp: Tidy up cpuinfo init and cpufeature updates
arm64: smp: Tidy up smp_prepare_cpus()
arm64: cpufeature: Store every ID register with its overrides applied
arm64: cpufeature: Read MPAMIDR_EL1 in __cpuinfo_store_cpu()
arm64: cpufeature: Add read_cpuid_with_overrides()
arm64: cpufeature: Check arm64_ftr_regs[] before the first store
* for-next/sysreg:
: sysreg updates
perf: arm_brbe: Remove the check for TME transaction states
arm64: sysreg: Mark fields the architecture dropped as RES0
arm64: sysreg: Fix the names of two misspelt fields
arm64: sysreg: Fix three incorrect enum values
* for-next/gcs:
: GCS updates/fixes
kselftest/arm64: Check for -EPERM not -EBUSY in the locking test
arm64: gcs: Return -EPERM not -EBUSY for prctl() locking failures
* for-next/fw-rmi: : RMM v2.0 base RMI support firmware: arm_rmm: hotplug: Skip memory added to ZONE_MOVABLE firmware: arm_rmm: Add wrappers for Realm related RMI commands arm64: Block hibernate and kexec while RMM is active PM: hibernate: Add an arch hook for preventing hibernation firmware: arm_rmm: Ensure the RMM has GPT entries for memory firmware: arm_rmm: Activate the RMM firmware: arm_rmm: Add support for SRO firmware: arm_rmm: Configure the RMM with the host's page size firmware: arm_rmm: Check for RMI support at init firmware: arm_rmm: Add SMC definitions for calling the RMM arm64: mm: Handle Granule Protection Faults (GPFs)
receive_encrypted_read() sets *num_mids = 1 and never writes the
caller's bufs[]. Offload returns -1 with *num_mids = 0, so the
demultiplex thread skips the frame. The inline decrypt path
returns 0 even when smb2_find_mid() fails.
cifs_demultiplex_thread() then treats mids[i] == NULL as an
oplock break and calls is_oplock_break(bufs[i], server) with
bufs[i] still NULL. smb2_is_valid_oplock_break() reads
hdr.Command at offset 12 and oopses.
A large encrypted READ whose MessageId does not match is enough
to panic cifsd.
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range
[0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 100 Comm: cifsd
RIP: smb2_is_valid_oplock_break+0xc8/0x2270 [cifs]
cifs_demultiplex_thread
Kernel panic - not syncing: Fatal exception
Return -1 when inline decrypt finds no mid, and skip
is_oplock_break() plus the unknown-frame dump when bufs[i]
is NULL. receive_encrypted_standard() already assigns
bufs[*num_mids].
Fixes: c42a6ab ("CIFS: Add capability to decrypt big read responses")
Assisted-by: LLM
Signed-off-by: Zikang Gao <2715417602@qq.com>
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: stable@vger.kernel.org
When a decrypted SMB2 READ response carries a MessageId that matches no outstanding request, both the inline receive_encrypted_read() and the offloaded smb2_decrypt_offload() paths drop the frame without accounting the credits the server granted in it. The plaintext unknown-frame path in cifs_demultiplex_thread() already reclaims them with smb2_add_credits_from_hdr(), so encrypted reads leak credits that the plaintext path would not. This also happens for legitimate frames - e.g. a reply that arrives after the client has timed out and dropped the mid - so over a long-lived connection the client's credit count drifts down and can eventually starve it of the ability to issue requests. The frame is AEAD-authenticated, so the granted credits in the decrypted header come from the real server and are safe to apply. Reclaim the credits from the decrypted header before dropping the frame, and export smb2_add_credits_from_hdr() so the SMB2 receive paths can use it. Fixes: c42a6ab ("CIFS: Add capability to decrypt big read responses") Fixes: 35cf94a ("smb3: allow parallelizing decryption of reads") Signed-off-by: Paulo Alcantara <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: Namjae Jeon <linkinjeon@kernel.org> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Shyam Prasad N <sprasad@microsoft.com> Cc: Tom Talpey <tom@talpey.com> Cc: Bharath SM <bharathsm@microsoft.com> Cc: stable@vger.kernel.org
I recently got a new job; update my mailmap entry to indicate my new legal work email address (though I'm not sure I will use it in the very near future). Signed-off-by: Gao Xiang <xiang.gao@docker.com> Acked-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <xiang@kernel.org>
z_erofs_load_lz4_config() rejects a valid LZ4 image when the kernel's page size differs from the image's block size. It bounds the on-disk max_pclusterblks with erofs_blknr(sb, Z_EROFS_PCLUSTER_MAX_SIZE), which expands to Z_EROFS_PCLUSTER_MAX_SIZE >> sb->s_blocksize_bits. At the point this runs, sb->s_blocksize_bits still holds PAGE_SHIFT: erofs_fc_fill_super() seeds s_blocksize_bits to PAGE_SHIFT before reading the superblock, and only corrects it down to the on-disk blkszbits after erofs_read_superblock() returns. The LZ4 config is parsed inside erofs_read_superblock(), before that correction, so the bound is computed with the wrong shift. On a 64K-page kernel mounting a 4K-block image (e.g. one built with mkfs.erofs -C 262144 on a 4K-page host), the bound evaluates to 1 MiB >> 16 = 16 blocks instead of the correct 1 MiB >> 12 = 256 blocks. The image's legitimate max_pclusterblks of 64 then fails the check, mount returns -EINVAL, and booting from such an image as the root filesystem panics: erofs (device dm-0): too large lz4 pclusterblks 64 Kernel panic - not syncing: VFS: Unable to mount root fs sbi->blkszbits already holds the on-disk block size at this point, so compute the bound from it directly. This makes the check independent of the host page size and of superblock-parse ordering. commit 3acea5f ("erofs: avoid hardcoded blocksize for subpage block support") already handled the same ordering hazard for the superblock checksum path by using sbi->blkszbits in erofs_superblock_csum_verify(); the lz4 config path was missed. Fixes: 3acea5f ("erofs: avoid hardcoded blocksize for subpage block support") Cc: stable@vger.kernel.org Assisted-by: Kirocrew:gpt-5.6-sol Signed-off-by: Gyokhan Kochmarla <gyokhan@amazon.de> Reviewed-by: Gao Xiang <xiang@kernel.org> Signed-off-by: Gao Xiang <xiang@kernel.org>
gfs2_freeze_lock_shared() takes sdp->sd_freeze_gl without the LM_FLAG_TRY or LM_FLAG_TRY_1CB flags, so gfs2_glock_nq_init() will never return GLR_TRYFAILED. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Upgrade the Poly1305 functions from 32-bit lengths to size_t. 'size_t' is the best practice for buffer lengths, and it's what the rest of the crypto library uses. Moreover, all the 64-bit Poly1305 assembly functions actually already treated the length as 64-bit, despite it being declared as 32-bit in C on arm64, mips64, ppc64, and riscv64: - On arm64, this caused unspecified behavior due to the high 32 bits having an unspecified value in that architecture's ABI. However, in practice these bits are always zero and no issue occurred. (ppc64 was fine too, since there the ABI zero-extends 32-bit arguments.) - On mips64 and riscv64, this caused incorrect behavior on lengths above S32_MAX, due to the sign extension done by those architectures' ABIs. Note that no current callers pass lengths over S32_MAX. Also, the expression 'desc->buflen + nbytes >= POLY1305_BLOCK_SIZE' in poly1305_update() could overflow if nbytes was in [UINT_MAX - 14, UINT_MAX]. Note that again, no current callers pass lengths this large. These issues date to the original introduction of the Poly1305 code. However, as noted above, they don't have any real-world impact currently; so this is an API robustness improvement only. Reported-by: Vladimir Kukharenko <vladimir@genproof.com> Closes: https://lore.kernel.org/r/20261012-libcrypto-4gib-lengths-v1-0-ea566c129a2e@genproof.com Tested-by: Vladimir Kukharenko <vladimir@genproof.com> Link: https://patch.msgid.link/20261014152604.323310-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Upgrade the ChaCha functions from 32-bit lengths to size_t. 'size_t' is the best practice for buffer lengths, and it's what the rest of the crypto library uses. Moreover, all the 64-bit ChaCha assembly functions actually already treated the length as 64-bit, despite it being declared as 32-bit in C on arm64, ppc64, and x86_64. For arm64 and x86_64, this caused unspecified behavior due to the high 32 bits of the corresponding register having an unspecified value in those architectures' ABIs. However, in practice these bits are always zero and no issue occurred. (ppc64 was fine too, since there the ABI zero-extends 32-bit arguments.) These issues date to the original introduction of the ChaCha code. However, as noted above, they don't have any real-world impact currently; so this is an API robustness improvement only. Reported-by: Vladimir Kukharenko <vladimir@genproof.com> Closes: https://lore.kernel.org/r/20261012-libcrypto-4gib-lengths-v1-0-ea566c129a2e@genproof.com Tested-by: Vladimir Kukharenko <vladimir@genproof.com> Link: https://patch.msgid.link/20261014152604.323310-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
chacha_doarm() compares the remaining length with signed conditions (blt, movle/movgt, bgt), and DIV_ROUND_UP(bytes, CHACHA_BLOCK_SIZE) in chacha_crypt_arch() wraps above 0xffffffc0, so lengths of 2 GiB or more are mishandled. size_t is 32 bits on arm, so declaring the length as size_t does not avoid this. On a Cortex-A7, an in-place chacha20_crypt() of 2 GiB + 4101 bytes changed only one byte. Use unsigned conditions (blo, movls/movhi, bhi) and DIV_ROUND_UP_POW2(). This affects the scalar code, which is used when NEON isn't usable and always on Cortex-A5 and Cortex-A7. No in-tree caller passes such lengths. Tested in QEMU on a Cortex-A7 with CONFIG_VMSPLIT_1G. An LLM review of this code found the bug. Assisted-by: LLM Signed-off-by: Vladimir Kukharenko <vladimir@genproof.com> Link: https://patch.msgid.link/20261014-libcrypto-chacha-32bit-2gib-v1-1-e0719ca0be89@genproof.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
The MIPS ChaCha assembly, which is chacha_crypt_arch() itself, tests the remaining length with signed branches, so for 2 GiB + 64 bytes or more it takes the final partial block path too early and processes less than requested. It is only used on 32-bit kernels, where size_t is 32 bits, so declaring the length as size_t does not avoid this. No in-tree caller passes such lengths. The partial block code also keeps the remaining length as a negative value, so instead of changing the assembly, rename it to chacha_crypt_mips() and add a C chacha_crypt_arch() that passes it at most 1 GiB per call. Tested in QEMU user mode: with a length of 0xfffff045 the assembly processed about 4 KiB and advanced the block counter by 64; with the same 1 GiB loop in C, a 1.25 GiB + 4101 byte buffer matches a C reference. An LLM review of this code found the bug. Assisted-by: LLM Signed-off-by: Vladimir Kukharenko <vladimir@genproof.com> Link: https://patch.msgid.link/20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
The `<linux/unaligned.h>` header is included but never actually used. The code handles memory accesses using memcpy() instead of the unaligned helpers. Remove this unused header to avoid false dependencies. Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com> Link: https://patch.msgid.link/20261016023558.8797-1-raizudeen.kerneldev@gmail.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
In the Meta fleet, we found PSI trigger destruction waiting for an RCU grace period while holding kernfs node_mutex, blocking other users [1]. File close and node drain hold this mutex while calling the release callback. Cgroup removal and disabling cgroup.pressure also hold cgroup_mutex during the drain. The wait was added by commit 0e94682 ("psi: introduce psi monitor") to protect worker and trigger lookups. Commit 461daba ("psi: eliminate kthread_worker from psi trigger scheduling mechanism") replaced the worker queue with a group timer. The scheduler now only checks whether rtpoll_task is NULL; it uses neither the task nor the trigger. Commit a06247c ("psi: Fix uaf issue when psi trigger is destroyed while being polled") removed trigger replacement and polling's RCU lookup. Trigger lists are protected by mutexes. Proc poll/select entries are removed before their file references are dropped. eventpoll_release() removes epoll entries before the file release callback. Commit aff0370 ("sched/psi: use kernfs polling functions for PSI trigger polling") moved cgroup polling to a kernfs waitqueue whose lifetime follows the file. A late timer firing only wakes the group waitqueue. The system group is static, and commit 5457025 ("sched/psi: Shut down rtpoll_timer in psi_cgroup_free()") shuts down the cgroup timer before freeing the group. Cgroup reclamation already waits for scheduler readers. Remove synchronize_rcu() from psi_trigger_destroy() and use rcu_access_pointer() for the worker NULL check. Keep kthread_stop() outside the trigger mutex. Tested trigger churn, notifications and cgroup removal in an 8-CPU VM with KASAN, lockdep, and full and lazy preemption. No warnings were found. Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Tejun Heo <tj@kernel.org> Link: https://github.com/bpftrace/user-tools/tree/master/runnablelockmonitor [1] Link: https://patch.msgid.link/20261010191500.3895736-1-shakeel.butt@linux.dev
On idle exit the dyntick-idle accounting accounts the time up to now, then the tick is restarted on its old period. The first tick accounts a whole TICK_NSEC to whatever runs, although the part of that period before the idle exit has just been accounted as idle time, or with IRQ_TIME_ACCOUNTING as IRQ time. That is up to a full tick per idle exit, and /proc/stat reports more idle time than wall time. Record how much of the current tick period dyntick-idle has accounted, and leave it out of the tick that ends the period. Fixes: cf6444c ("tick/sched: Unify idle cputime accounting") Signed-off-by: Stian Halseth <stian@itx.no> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/20261004142724.3896396-1-stian@itx.no/ Link: https://patch.msgid.link/20261007142950.547604-1-stian@itx.no
update_sg_lb_stats() sums utilization over the CPUs in both sched_group_span(group) and env->cpus, but takes capacity from group->sgc->capacity for the whole group. record_sg_llc_stats() publishes both. Rejecting an all-affinity-pinned source runqueue removes that CPU from env->cpus and retries group selection. The retry can publish the partial utilization with the full capacity. can_migrate_llc() then treats a busy preferred LLC as having spare capacity. More tasks can aggregate into it, migrations out can be blocked, and two busy LLCs may not fall back to generic balancing. This increases CPU contention and task latency. Found by inspection. Skip publication on affinity retries using LBF_ALL_PINNED, retaining the first-pass snapshots and avoiding repeated cpumask checks. On the first pass, publish either shared LLC statistic only when env->cpus covers the whole group. Load balancing still uses the affinity-filtered statistics. The same window exists during CPU hotplug. env->cpus drops a CPU at set_cpu_active(false), but the group span and sgc->capacity still include it until cpuset_cpu_inactive() rebuilds the domains. Keeping the previous snapshot avoids the mismatched publish. After the rebuild, the next periodic balance records both statistics again. Fixes: f025ef2 ("sched/cache: Record per LLC utilization to guide cache aware scheduling decisions") Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Jemmy Wong <jemmywong512@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20261013084338.55100-1-jemmywong512@gmail.com
This reverts commit 819224e. The cfs_rq->curr == se case can actually happen with CFS_BANDWIDTH, so the removed code is needed. Document this. Fixes: 819224e ("sched/fair: Remove dead code on enqueue_task_fair()") Reported-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Kayra Cizmeci <kayracizmeci@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/lkml/fd3f9d83-cb5b-496b-b7c1-b40f31cf795e@arm.com/ Link: https://patch.msgid.link/20261015082919.4344-1-kayracizmeci@gmail.com
The menu governor was the last consumer of the per-CPU I/O-wait count that needed its magnitude, apart from nr_iowait() summing it globally. Commit 38f8309 ("cpuidle: menu: Remove iowait influence") removed that use. All remaining per-CPU consumers only test for zero/nonzero. Replace nr_iowait_cpu() with bool cpu_has_iowait() and update the generic and s390 idle accounting callers. Have nr_iowait() read the counters directly so that the global total and existing accounting are preserved. Replace the stale menu comment with a description of the predicate. Also convert the remaining open-coded idle accounting checks to use the predicate, as suggested by Prateek. The conversion was done with coccinelle: @ predicate depends on patch @ expression cpu; @@ - nr_iowait_cpu(cpu) > 0 + cpu_has_iowait(cpu) @ callers depends on patch @ expression cpu; @@ - nr_iowait_cpu(cpu) + cpu_has_iowait(cpu) Signed-off-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://patch.msgid.link/20261016073341.575472-1-christian.loehle@arm.com
reserve_ext_regs_buffers() wraps the per-CPU ext_regs_buf allocation in WARN_ON_ONCE(). The allocator already prints a warning with a stack dump when a GFP_KERNEL allocation fails, so the WARN only repeats it, which Documentation/process/coding-style.rst asks not to do. The failure is also handled: the buffers are freed again, the event is still created, and events that ask for SIMD or extended register sampling are rejected with -ENOMEM in x86_pmu_hw_config() and event_simd_regs_validate(). syzkaller hit this with fault injection on next-20261002. The trigger is a plain hardware cycles event opened while no other x86 PMU event exists, with the allocation failed: !per_cpu(ext_regs_buf, cpu) WARNING: arch/x86/events/core.c:441 at reserve_ext_regs_buffers arch/x86/events/core.c:441 [inline] WARNING: arch/x86/events/core.c:441 at x86_reserve_hardware+0x6ff/0x880 arch/x86/events/core.c:458 Call Trace: __x86_pmu_event_init arch/x86/events/core.c:825 [inline] x86_pmu_event_init+0x109/0xc50 arch/x86/events/core.c:3003 perf_try_init_event+0x140/0xbc0 kernel/events/core.c:13261 perf_init_event kernel/events/core.c:13365 [inline] perf_event_alloc+0x2145/0x5680 kernel/events/core.c:13640 __do_sys_perf_event_open+0x669/0x2d40 kernel/events/core.c:14185 do_syscall_64+0x12c/0x7b0 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Drop the WARN_ON_ONCE(). This matches reserve_ds_buffers() and reserve_lbr_buffers(), which also handle allocation failure without a warning. Fixes: b84c962 ("perf/x86: Enable XMM register sampling for non-PEBS events") Assisted-by: Claude:claude-opus-5-5 syzkaller Signed-off-by: vineash <vineash30640@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/179187920064.3441876.15687522011658301558@gmail.com
Stacked file-systems might call d_alloc_parallel() in another file-system while holding an in-lookup dentry is this filesystem. In order for lockdep not to report that, we give each file-system-type a different lockdep key for in-lookup locking. This matches what is already done for lockdep tracking of i_rwsem. Fixes: 59492f9 ("VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.") Signed-off-by: NeilBrown <neil@brown.name> Link: https://patch.msgid.link/20261002223746.3248726-2-neilb@ownmail.net Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
lockdep has a number of macros which assume the lockdep_map is in a field called "dep_map". If dentry.lookup_map is renamed to dep_map these macros can be used. In this patch we can now use might_lock(). In future lockdep_set_class() will be used. Fixes: 59492f9 ("VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.") Signed-off-by: NeilBrown <neil@brown.name> Link: https://patch.msgid.link/20261002223746.3248726-3-neilb@ownmail.net Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Now that d_alloc_parallel() locking is tracked by lockdep, ovl needs to take care that it doesn't trigger on deliberate recursion into subordinate filesystems. As ovl can stack over itself, the use of the per-file_system_type d_lookup_key is not enough. So provide a .d_init() function to update the map as it already done for i_rwsem and ovl_inode.lock. Reported-and-tested-by: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/all/e3772a51-eabc-4c31-b73d-f3187bf1b3b2@intel.com/ Fixes: 59492f9 ("VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.") Signed-off-by: NeilBrown <neil@brown.name> Link: https://patch.msgid.link/20261002223746.3248726-4-neilb@ownmail.net Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
…esystems" NeilBrown <neilb@ownmail.net> says: The recent addition of lockdep tracking for in-lookup dentries didn't take into account the needs of stacking filesystems. For this we need different lock keys for different filesystems in the stack. * patches from https://patch.msgid.link/20261002223746.3248726-1-neilb@ownmail.net: ovl: provide private lockdep class for dentry->dep_map VFS: rename lookup_map to dep_map VFS: per-fs-type lockdep key for dentry in-lookup locking Link: https://patch.msgid.link/20261002223746.3248726-1-neilb@ownmail.net Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Cachefiles currently uses the backing filesystem's idea of what data is
held in a backing file and queries this by means of SEEK_DATA and
SEEK_HOLE. However, this means it does two seek operations on the backing
file for each individual read call it wants to prepare (unless the first
returns -ENXIO). Worse, the backing filesystem is at liberty to insert or
remove blocks of zeros in order to optimise its layout which may cause
false positives and false negatives.
The problem is that keeping track of what is dirty is tricky (if storing
info in xattrs, which may have limited capacity and must be read and
written as one piece) and expensive (in terms of diskspace at least) and is
basically duplicating what a filesystem does.
However, the most common write case, in which the application does {
open(O_TRUNC); write(); write(); ... write(); close(); } where each write
follows directly on from the previous and leaves no gaps in the file is
reasonably easy to detect and can be noted in the primary xattr as
CACHEFILES_CONTENT_ALL, indicating we have everything up to the object size
stored.
In this specific case, given that it is known that there are no holes in
the file, there's no need to call SEEK_DATA/HOLE or use any other mechanism
to track the contents. That speeds things up enormously.
Even when it is necessary to use SEEK_DATA/HOLE, it may not be necessary to
call it for each cache read subrequest generated.
Implement this by adding support for the CACHEFILES_CONTENT_ALL content
type (which is defined, but currently unused), which requires a slight
adjustment in how backing files are managed. Specifically, the driver
needs to know how much of the tail block is data and whether storing more
data will create a hole.
To this end, the way that the size of a backing file is managed is changed.
Currently, the backing file is expanded to strictly match the size of the
network file, but this can be changed to carry more useful information.
This makes two pieces of metadata available: xattr.object_size and the
backing file's i_size. Apply the following schema:
(a) i_size is always a multiple of the DIO block size.
(b) i_size is only updated to the end of the highest write stored. This
is used to work out if we are following on without leaving a hole.
(c) xattr.object_size is the size of the network filesystem file cached
in this backing file.
(d) xattr.object_size must point after the start of the last block
(unless both are 0).
(e) If xattr.object_size is at or after the block at the current end of
the backing file (ie. i_size), then we have all the contents of the
block (if xattr.content == CACHEFILES_CONTENT_ALL).
(f) If xattr.object_size is somewhere in the middle of the last block,
then the data following it is invalid and must be ignored.
(g) If data is added to the last block, then that block must be fetched,
modified and rewritten (it must be a buffered write through the
pagecache and not DIO).
(h) Writes to cache are rounded out to blocks on both sides and the
folios used as sources must contain data for any lower gap and must
have been cleared for any upper gap, and so will rewrite any
non-data area in the tail block.
To implement this, the following changes are made:
(1) cookie->object_size is no longer updated when writes are copied into
the pagecache, but rather only updated when a write request completes.
This prevents object size miscomparison when checking the xattr
causing the backing file to be invalidated (opening and marking the
backing file and modifying the pagecache run in parallel).
(2) The cache's current idea of the amount of data that should be stored
in the backing file is kept track of in object->object_size.
Possibly this is redundant with cookie->object_size, but the latter
gets updated in some addition circumstances.
(3) The size of the backing file at the start of a request is now tracked
in struct netfs_cache_resources so that the partial EOF block can be
located and cleaned.
(4) The cache block size is now used consistently rather than using
CACHEFILES_DIO_BLOCK_SIZE (4096).
(5) The backing file size is no longer adjusted when looking up an object.
(6) When shortening a file, if the new size is not block aligned, the part
beyond the new size is cleared. If the file is truncated to zero, the
content_info gets reset to CACHEFILES_CONTENT_NO_DATA.
(7) A new struct, fscache_occupancy, is instituted to track the region
being read. Netfslib allocates it and fills in the start and end of
the region to be read then calls the ->query_occupancy() method to
find and fill in the extents. It also indicates whether a recorded
extent contains data or just contains a region that's all zeros
(FSCACHE_EXTENT_DATA or FSCACHE_EXTENT_ZERO).
(8) The ->prepare_read() cache method is changed such that, if given, it
just limits the amount that can be read from the cache in one go. It
no longer indicates what source of read should be done; that
information is now obtained from ->query_occupancy().
(9) A new cache method, ->collect_write(), is added that is called when a
contiguous series of writes have completed and a discontiguity or the
end of the request has been hit. It it supplied with the start and
length of the write made to the backing file and can use this
information to update the cache metadata.
(10) cachefiles_query_occupancy() is altered to find the next two "extents"
of data stored in the backing file by doing SEEK_DATA/HOLE between the
bounds set - unless it is known that there are no holes, in which case
a whole-file first extent can be set.
(11) cachefiles_collect_write() is implemented to take the collated write
completion information and use this to update the cache metadata, in
particular working out whether there's now a hole in the backing file
requiring future use of SEEK_DATA/HOLE instead of just assuming the
data is all present.
It also uses fallocate(FALLOC_FL_ZERO_RANGE) to clean the part of a
partial block that extended beyond the old object size. It might be
better to perform a synchronous DIO write for this purpose, but that
would mandate an RMW cycle. Ideally, it should be all zeros anyway,
but, unfortunately, shared-writable mmap can interfere.
(12) cachefiles_begin_operation() is updated to note the current backing
file size and the cache DIO size.
(13) cachefiles_create_tmpfile() no longer expands the backing file when it
creates it.
(14) cachefiles_set_object_xattr() is changed to use object->object_size
rather than cookie->object_size.
(15) cachefiles_check_auxdata() is altered to actually store the content
type and to also set object->object_size. The cachefiles_coherency
tracepoint is also modified to display xattr.object_size.
(16) netfs_read_to_pagecache() is reworked. The cache ->prepare_read()
method is replaced with ->query_occupancy() as the arbiter of what
region of the file is read from where, and that retrieves up to two
occupied extents of the backing file at once.
The cache ->prepare_read() method is now repurposed to be the same as
the equivalent network filesystem method and allows the cache to limit
the size of the read before the iterator is prepared.
netfs_single_dispatch_read() is similarly modified.
(17) netfs_update_i_size() and afs_update_i_size() no longer call
fscache_update_cookie() to update cookie->object_size.
(18) Write collection now collates contiguous sequences of writes to the
cache and calls the cache ->collect_write() method.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260910220242.2165023-5-dhowells@redhat.com
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: linux-cifs@vger.kernel.org
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
With a really small cache, cachefiles is likely to see a lot of writes hitting ENOSPC - and this can include setxattr that sets the state xattr on a cachefile - but we don't really want to successfully fill a cache file only to have to scrap it because we can't set the xattr. Instead, preset the xattr when we create the tmpfile we're going to use, and scrap the file at that point if we get ENOSPC. Only if setxattr succeeds do we allow data to be written to the file. Note that there is a potential performance loss in that writes to the cache have to be delayed until this is completed - but we do the tmpfile/setxattr in parallel, starting when the file is opened and only have to wait once writeback occurs. Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260910220242.2165023-6-dhowells@redhat.com Reviewed-by: Paulo Alcantara <pc@manguebit.org> cc: Marc Dionne <marc.dionne@auristor.com> cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
…cupancy tracking-related"
David Howells <dhowells@redhat.com> says:
Cachefiles is modified to better implement caching for the class of files
that are opened new/truncated, written once sequentially with no seeking
and then closed (ie. the most common class):
(1) The object type in the cachefiles file xattr is now correctly set to
CACHEFILES_CONTENT_{SINGLE,ALL,BACKFS_MAP} rather than just being 0,
to indicate whether we have one of: a single monolithic blob, all the
data up to cache i_size with no holes or a sparse file with the data
mapped by the backing file system (as currently upstream).
(2) For "ALL" type files, the cache's i_size is used to track how much
data is saved in the cache and no longer bears any relation to the
netfs i_size. The actual object size is stored in the xattr.
(3) For most typical files which are contiguous and written progressively,
the object type is now set to "ALL". For anything else, cachefiles
uses SEEK_DATA/HOLE to find extent outlines at before (this is the
current behaviour and needs to be fixed, but in a separate set of
patches as it's not trivial).
(4) Reads of "ALL" type files can then skip the SEEK_DATA/HOLE step to
determine the occupancy; backing file i_size and the object size field
stored in the state xattr suffice.
Other changes are also made:
(1) cachefile_do_prepare_read() is merged into cachefiles_prepare_read()
now that the ondemand mode stuff got removed.
(2) Some extra traces are added for write failure and insufficient space.
(3) The state xattr on a cachefile is pre-set to try to avoid having to
deal with ENOSPC from setxattr when committing the object.
* patches from https://patch.msgid.link/20260910220242.2165023-1-dhowells@redhat.com:
cachefiles: Preset the state xattr when creating a new file
cachefiles: Don't rely on backing fs storage map for most use cases
cachefiles: Add a tracepoint to log insufficient space errors
netfs, cachefiles: Add a couple of traces for write failure
cachefiles: Clean up cachefiles_do_prepare_read()
Link: https://patch.msgid.link/20260910220242.2165023-1-dhowells@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
fs/netfs/fscache_internal.h has been unused since commit 915cd30 ("netfs, fscache: Combine fscache with netfs"). Remove it. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260918024040.338737-1-enelsonmoore@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Fix cachefiles to set subreq->error before calling netfs_prepare_write_failed() otherwise netfslib will try (and fail) to retry the subrequest (it shouldn't retry writes to the cache, but rather abandon them). This causes it to hang waiting for the request to complete. Reported-by: Marc Dionne <marc.dionne@auristor.com> Fixes: 1a9fe4b ("cachefiles: Don't rely on backing fs storage map for most use cases") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/3227746.1790772118@warthog.procyon.org.uk Tested-by: Marc Dionne <marc.dionne@auristor.com> cc: Paulo Alcantara <pc@manguebit.org> cc: Matthew Wilcox <willy@infradead.org> cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Fix the resize handling in fscache and cachefiles by passing down a flag to indicate if the file is being shrunk as the cache's idea of how big the file should be may be stale and thus not useful in comparison to the object's size. The issue is that netfs_perform_write() updates the network filesystem's file's i_size as it adds data to the pagecache, but the cache isn't updated until writeback flushes that data. A truncation may then scrap that data and so the cache never sees it and doesn't update before it is told to resize. In the resize, cachefiles was comparing the new size against the current cache size and then thinking the file was being expanded. Note that this is a bit more complicated for ceph than other filesystems as ceph splits the truncation of the local pagecache and fscache to after the RPC reply handler has updated the inode record - the reply handler communicates the need for the truncation finalisation through ceph inode flags. To this end, ceph is changed such that the outstanding truncation count in the inode turns into a bool and just set instead of being incremented (the code only cares if it's zero or non-zero) and then a second bool is added to record if the file was being shrunk. Reported-by: Marc Dionne <marc.dionne@auristor.com> Fixes: 1a9fe4b ("cachefiles: Don't rely on backing fs storage map for most use cases") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/1091807.1791483394@warthog.procyon.org.uk Reviewed-by: Alex Markuze <amarkuze@redhat.com> cc: Ilya Dryomov <idryomov@gmail.com> cc: Alex Markuze <amarkuze@redhat.com> cc: Viacheslav Dubeyko <slava@dubeyko.com> cc: Paulo Alcantara <pc@manguebit.org> cc: Matthew Wilcox <willy@infradead.org> cc: v9fs@lists.linux.dev cc: linux-afs@lists.infradead.org cc: ceph-devel@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use a typical list style for comments to prevent kernel-doc warnings: Documentation/filesystems/api-summary:20: ../fs/dcache.c:2029: ERROR: Unexpected indentation. [docutils] Documentation/filesystems/api-summary:20: ../fs/dcache.c:2030: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] Also, modify the spelling of "whiteout" to match all other uses in the kernel source tree and to be consistent on the same line. Fixes: 33d7651 ("VFS: add d_duplicate()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20261001021745.2160005-1-rdunlap@infradead.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Daniel Micay <danielmicay@gmail.com> Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Previously we would read randomize_va_space in openpax_setup_flags, and then again later after calling openpax_setup_flags. As randomize_va_space is a sysctl, its value can change at any time. Accordingly, snapshot randomize_va_space before calling openpax_set_flags and pass the snapshot value to openpax_set_flags. This resolves a minor race condition where one may be able to slightly weaken process ASLR by turning ASLR on or off during an exec call. Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Otherwise we have to add a bunch of #ifdefs when we otherwise would not need to. Fixes: a78588f ("init: add pax_softmode= kernel command-line option") Fixes: edera-dev#1 Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
XENMEM_populate_physmap takes an extent order, but the only wrapper exposed here pins it to EXTENT_ORDER, the order that covers one native page and nothing more. Add a variant that takes an additional order, so a caller can ask Xen to back a run of pages with a single machine-contiguous allocation rather than one frame per page. For a PV domain Xen reports back only the base machine frame of each ordered extent, the rest of the extent following it. For a PVH domain it reports nothing, as the guest never handles machine frames. No functional change: xenmem_reservation_increase() becomes a wrapper at order 0 and the new variant has no callers yet. Backends: PV, PVH Direction: deflate (frames move from Xen to the guest) Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means rewriting its direct map PTE through Xen. The
per-page helpers in drivers/xen/mem-reservation.c make one
HYPERVISOR_update_va_mapping call per page.
Add exported helpers that do the same for a contiguous run in batches,
through HYPERVISOR_mmu_update as xen_remap_pfn() does:
- xen_zap_contig_pfns() unmaps a run and invalidates its p2m entries,
for pages about to be handed to Xen.
- xen_remap_contig_pfns() maps a run onto frames Xen has just
populated. It writes the p2m with __set_phys_to_machine(), which
never allocates, so the caller runs xen_prealloc_p2m_range() over
the run first, before the populate hypercall, while a failure can
still be backed out of.
Both return the first failure, whether a PTE they could not find or Xen
refused to update, or a p2m entry that could not be written, and leave
what to do about it to the caller. mmu_update reports a failure back to its caller, where a
multicall batch would only log it.
Neither flushes the TLB: the intended caller only maps over PTEs that
were already cleared, and flushes after unmapping itself.
PVH domains never reach these: their page tables hold guest frames,
which do not change when Xen moves the machine frames behind them.
No callers yet.
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means updating its direct map PTE and p2m entry. The
existing helpers for that take parallel arrays of pages and frames, one
entry per page. That fits order-0 extents, where Xen reports a frame per
page, but not an ordered extent, where it reports only the base frame.
Add variants that take a base page, and for mapping a base frame, and
derive the rest of a contiguous run from them, on top of the batched arch
helpers:
- xenmem_reservation_va_mapping_reset_contig() unmaps a run before its
frames are handed to Xen.
- xenmem_reservation_p2m_prealloc() and
xenmem_reservation_va_mapping_update_contig() map a run in once Xen
has populated it. The mapping step cannot allocate, so the
preallocation is a separate call, made before asking Xen to
populate: it is the only step expected to fail, and failing after
the populate would strand the frames Xen handed over.
The two directions treat a failed update differently:
- A failed map is fatal, as in the per-page helper. Callers treat the
run as mapped once the call returns, and a page with no mapping
would fault wherever it was next used, far from the cause.
- A failed unmap only warns, unlike the per-page helper. The frame
stays mapped, and Xen will not hand it to another domain while it
is, so the frame leaks but nothing is corrupted.
All three are no-ops outside a PV domain, like the helpers they sit
beside.
No functional change: the new helpers have no callers yet.
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
The balloon inflates a page at a time: it takes whatever pages the guest
buddy allocator hands out and returns their frames to Xen one order-0
extent each. Those frames need not form an aligned run, so Xen's
free_heap_pages() cannot merge them back into a 2 MiB buddy.
Add a second unit of trade, a block of 1 << 9 Xen pages: 2 MiB, the
largest extent Xen grants a domain asking on its own behalf. Inflate now
takes a whole free block with one alloc_pages() and parks it on a block
list, so its frames go back to Xen as an aligned run. On PV the block is
unmapped with the batched contiguous-run helper; on PVH there is nothing
to unmap.
The extents submitted stay order-0. XENMEM_decrease_reservation
releases each frame individually whatever the extent order, so an
ordered extent would change nothing there while asking Xen to trust that
the block is machine-contiguous, a claim it cannot check for a PV
domain, where the frame number it is handed is already the machine
frame.
A block is only an option, never a requirement, in either direction:
- balloon_inflate() takes a block only when the guest has a whole free
2 MiB run, without reclaiming or compacting to make one, and
otherwise inflates a page at a time. A guest with plenty of free
memory can still have no such run, and that must not stop it
shrinking.
- Deflate still populates a page at a time and walks only the page
list, which cannot see blocks. When that list is empty it now breaks
a parked block onto it, so the guest can always grow back into
memory it gave up as a block.
The OOM notifier sized its deflate from the page list counters alone,
so a balloon holding only blocks would look empty to it and the OOM
killer would run while the balloon still held memory. It now counts
block pages too, and its deflate reaches them through the block-breaking
path above.
Set xen.balloon_superpages=0 to inflate a page at a time as before.
Backends: PV, PVH
Direction: inflate (frames move from the guest to Xen); deflate only
changes to consume blocks
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
Deflate still breaks a parked block into pages and asks Xen to populate
each with its own order-0 extent, which lets Xen back the block with any
512 frames it has.
Populate a parked block as a single order-9 extent instead, so that Xen
allocates one machine-contiguous 2 MiB run for it:
- On PVH Xen maps that run with a single 2 MiB EPT entry rather than
512 4 KiB ones.
- On PV there is no EPT, and the guest cannot use 2 MiB mappings. The
guest maps the run in itself, with the batched contiguous-run
helper, from the base machine frame Xen reports.
The p2m leaves of each block are preallocated while walking the block
list, before the populate hypercall: mapping the block afterwards cannot
allocate, and once Xen has populated an extent there is no way to hand
it back. Failing there only shortens the batch.
A block is only an option here too. balloon_deflate() falls back to the
page at a time path when a block makes no progress: Xen refuses an
order-9 extent when the host has no free 2 MiB run, or when the domain
is less than 2 MiB below its max_pages ceiling, and neither should stop
the guest growing by what it can still get. Credits smaller than a block
take the page at a time path as well.
Blocks are populated at most BALLOON_BLOCK_BATCH at a time, which bounds
the work done under balloon_mutex; the OOM notifier can only trylock it.
Backends: PV, PVH
Direction: deflate (frames move from Xen to the guest)
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
The OOM notifier deflates through increase_reservation(), which works a page at a time and reaches parked blocks only by breaking them up. Deflate through balloon_deflate() instead, so that an OOM deflate populates a whole block as a single order-9 extent where Xen can supply one, and still falls back to single pages where it cannot, including the last 2 MiB below the domain's max_pages ceiling. Backends: PV, PVH Direction: deflate (frames move from Xen to the guest) Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
xen_init_time_common() points x86_platform.calibrate_tsc at xen_tsc_khz() but leaves calibrate_cpu native, so tsc_early_init() -> determine_cpu_tsc_frequencies() still calls native_calibrate_cpu_early() for cpu_khz. That tries CPUID 0x16, then MSR_PLATFORM_INFO, and then falls through to quick_pit_calibrate() -- which on a PVH guest waits out its full 50ms timeout on a PIT that is not there, prints "Fast TSC calibration failed", and arrives at a value the hypervisor had already been asked for a moment later. It is 48ms of every boot, and it is the largest single item in one: a 512 MiB PVH guest reached "Run /init as init process" at 0.330s, and 0.118s once this and the xenbus boot wait were out of the way. There is nothing for the calibration to find out here. Xen reports the TSC frequency, tsc_khz already comes from it, and cpu_khz differing from tsc_khz under a hypervisor is not information -- determine_cpu_tsc_frequencies() would overwrite cpu_khz with tsc_khz anyway once they disagree by more than 10%. Note that tsc_early_khz= does not help: it only short-circuits calibrate_tsc, and the 50ms is spent in calibrate_cpu. Set in xen_init_time_common() so PV and PVH/HVM guests both get it, which is where calibrate_tsc is already set for the same reason. Signed-off-by: Alex Zenla <alex@edera.dev>
boot_wait_for_devices() sleeps HZ/10 between checks, so on a CONFIG_HZ=100 kernel it waits a tenth of a second to notice something that has already happened. What it is waiting for is not slow: a toolstack has every backend sitting in XenbusStateInitWait before it unpauses the guest, so the wait covers the frontend half of the handshake, which finishes a few milliseconds after the late_initcall starts looking. Measured on a PVH guest, the last frontend connected at 0.232s and init started at 0.311s -- 79ms of sleeping past the event. Frontends move to XenbusStateConnected (and blkfront sets is_ready) from their otherend_changed callback, which runs from the frontend bus's backend_changed() watch. Bump a sequence count and wake a wait queue there, and have wait_for_devices() sleep on it instead of for a fixed interval. The sequence is sampled before each check, so a change that lands between the check and the sleep still wakes the waiter. The HZ/10 interruptible sleep stays as the timeout, so state changes that do not come through the watch are noticed no later than before, and the 30/270-second budgets and their reporting are unchanged. Signed-off-by: Alex Zenla <alex@edera.dev>
Port the nightly upstream rebase from the Xen tree to the kernel. Every night at 03:23 UTC, Claude rebases edera/mainline onto torvalds master, following .automation/skills/upstream-rebase/SKILL.md: it replays the series, resolves conflicts, fixes what the replay broke, builds, audits upstream fixes that meet the series, and writes a report. The model's own account of its result decides nothing. It runs with a read-only token; its branch leaves the job as a git bundle and is judged by scripts taken from the commit the run started from: - verify-upstream-rebase.sh (unchanged from Xen) proves the series sits on the upstream tip, is linear, kept every commit, and moved the tree by exactly the upstream delta; - kernel-build.sh builds x86_64 and arm64 vmlinux with the Hyper-V, Xen dom0/backend, PV-IOMMU, NUMA affinity and OpenPaX options built in, and fails if olddefconfig drops any of them. If both pass and the report asks for no decision, edera/mainline is force-pushed with a lease pinned to the tip the rebase started from, and the old tip is kept as a backup branch. Otherwise the result goes up as a pull request carrying the report, and approving it lands it (rebase-land.yml). A night with no result opens an issue. Every job clones blobless: the jobs need the kernel's commit graph but only the contents of the files the series and upstream touch.
The rebase runs from a scheduled or dispatched event and needs its own federation rule rather than the organization-wide one, so read it from vars.REBASE_FEDERATION_RULE_ID.
edera/6.18-lts carries its own rebase automation, but scheduled workflows run only from the default branch. Add a workflow here whose only job is to dispatch edera/6.18-lts's kernel-nightly.yml each night.
OPENPAX currently defaults to y, which means OpenPaX gets enabled for any configuration that picks up the new symbol, including ones that never asked for it. Default it to n so it has to be selected explicitly. While at it, make OPENPAX_SOFTMODE depend on OPENPAX. Soft mode does nothing without OpenPaX enabled, so there is no reason for it to be selectable (and default y) on its own. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit 514cd60)
edera/6.18-lts proposes a backport of each pull request merged into edera/mainline, driven by its own workflows. Add a workflow here whose only job is to dispatch that, skipping pull requests labelled no-backport and the nightly's rebase pull requests.
xen-pciback seizes a hidden device in an fs_initcall, but the Xen IOMMU registered from a device_initcall. Registering probes every PCI device that already exists, so a hidden device was found with a driver bound and the IOMMU core warned about a late probe at driver bind. Register from subsys_initcall_sync instead, so the IOMMU is in place before pciback binds anything. Signed-off-by: Alex Zenla <alex@edera.dev>
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
All of the extra memory Linux reserves at boot goes to the mapping pool, so dom0's balloon starts empty. Growing dom0 at runtime then means memory hotplug, which places the new range at the first free physical address: on PVH that is the host's own map, where nothing guarantees the range is not a device's MMIO window. Keep the part of the extra memory dom0 may grow into on the balloon instead. Xen's ceiling for dom0 (dom0_mem=...,max:) sizes that part, so a host booted without a max: keeps today's behaviour. Every region gives up the same fraction, which spreads the growth over the NUMA nodes on PVH and leaves each node's mapping pool its share, and the last memory section stays with the pool so that early grant mappings never fall back to holes in the physical map. Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
A request that does not fit in its ring sleeps in io_wait_event_killable() until the backend frees space, but the event handler wakes the ring with wake_up_interruptible(), which only wakes TASK_INTERRUPTIBLE sleepers. A TASK_KILLABLE waiter therefore sleeps until it is killed, which hangs a guest that has enough large requests in flight to fill a ring. Wake the ring with wake_up() so killable waiters see the freed space. Fixes: 9523fea ("net/9p: Switch to wait_event_killable()") Signed-off-by: Alex Zenla <alex@edera.dev>
The frontend's resume handler only warned that suspend and resume are unsupported. After a restore its rings, grant references and event channels are gone, yet the mounted client kept writing requests into them, so every request on the mount hung. The next InitWait from the backend then allocated a second frontend instance for the same device, which no client used. On resume, collect any replies the backend left in the rings, free the rings, fail the requests that are still unanswered with -EIO, and publish Initialising so that a backend which still serves the old rings starts over. When the backend reaches InitWait, allocate and publish new rings for the existing frontend, keeping its clients. Requests that arrive while the frontend is not connected wait until it is, and a rw_semaphore keeps them off the rings while a resume replaces them. Signed-off-by: Alex Zenla <alex@edera.dev>
A forked, restored or imported domain resumes against a new backend whose fid table is empty, while the guest's 9P clients still hold the fids of the session they were suspended with. With the transport reconnected every request on those fids still fails, so even an idle mount comes back unusable. When the backend advertises feature-session-transfer, wait at suspend for the requests in flight to be answered, then ask the backend for its fid table with Tsession_save and keep the pages in guest memory, where they survive into whatever domain the guest resumes in. Once a restored frontend's new backend connects, replay the pages with Tsession_restore before any request can use the rings. The pages are opaque to the frontend; the backend validates every entry as it would a walk or open. Signed-off-by: Alex Zenla <alex@edera.dev>
The toolstack has to know whether a guest can carry its 9P session into a new backend before it exports the domain, because a guest that cannot comes back with every open file on its mounts unusable. Until now only the backend advertised the feature, and the frontend's support was invisible from dom0. Publish feature-session-transfer = 1 in the frontend's own xenstore directory, next to version and num-rings. Signed-off-by: Alex Zenla <alex@edera.dev>
arch/x86/xen/enlighten.c includes xen/interface/memory.h for XENMEM_maximum_reservation, but memory.h uses xen_ulong_t, domid_t and GUEST_HANDLE without including where they are defined, xen/interface/xen.h. Other configurations reach those through an earlier include. The zone-tiny configuration does not, and fails to build with CONFIG_WERROR=y: include/xen/interface/physdev.h:41:5: error: unknown type name 'xen_ulong_t' Include xen/interface/xen.h first, as arch/arm/xen/enlighten.c does. Signed-off-by: Alex Zenla <alex@edera.dev>
A node whose pool is short called fill_list() even when other nodes still held free pages. fill_list() takes new address space from iomem_resource, which on a PVH dom0 can overlap MMIO that Xen has identity mapped. A later grant map onto such a gfn makes Xen refuse the p2m change and crash dom0. Carve a new region only when every node's pool is short, and otherwise take pages from the preferred node first, then the others. Return pages to the pool of their own node when the PV p2m allocation fails.
…ode variant Borrowing across nodes made xen_alloc_unpopulated_pages_node() best effort, so a caller that asked for a node could get pages of another. The node variant now takes pages only from the requested node's pool and fails with -ENOMEM when it is short. It no longer carves a region. xen_alloc_unpopulated_pages() has no node requirement: it prefers the local pool, borrows from other nodes, and carves a region only when every pool is short. xenbus falls back to it when the node's pool is short, and gnttab_alloc_pages_node() uses it for NUMA_NO_NODE.
Author
|
Superseded by #46. |
edera-rebase-app
Bot
deleted the
rebase/edera-mainline/20261021-4e04beff425b-72a16bcff25e
branch
October 22, 2026 04:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nightly rebase of
edera/mainline(4e04beff425b) ontomaster(72a16bcff25e), driven by Claude. Not pushed automatically because the checker found drift. Run log.Important
Do not use the merge button: this branch replaces
edera/mainlinerather than merging into it. Approve the pull request to land it; the land workflow force-pushesedera/mainlineto the approved head, pinned to4e04beff425b, and keeps a backup.Independent checks
Builds: success (x86_64 and arm64 vmlinux with the Edera features built in; per-build results in the run).
4e04beff425b1f045c1846f2c03c1a14507d72a16bcff25eCommits whose hunk context moved (own +/- lines identical)
4dea901e50b7 xen-blkfront: place per-ring buffers on per-hctx nodes→8d93d5fe129bef5473f15598 xattr: add support for retrieving PaX flags stored in xattrs→b88d0ef9454fe29043736bdb arm64: determine stack entropy based on mmap entropy→068b7c466200Drift (changed lines: upstream delta vs. actual change)
Claude's report
Claude left no report (rebase step: success).