| Age | Commit message (Collapse) | Author |
|---|
|
struct bpf_insn_aux_data spreads its flags over eleven bools, a u8 of
three bit fields and a u32 group with 25 of its 32 bits spare. Put them
all in u64 bit fields, alu_state with them, which fit in the 32 bits
beside seen, so orig_idx starts the next word. The structure goes from
216 bytes to 200, and stays there when a later patch adds a u32, which
takes a hole further down.
alu_state was a u8, but it only ever holds BPF_ALU_* flags, the highest
of which is BPF_ALU_IMMEDIATE (1U << 4), so it gets five bits. With
eight, the flags would take 34 bits, more than fit beside seen, so they
would start a word of their own, and the later u32 would grow the
structure to 208 bytes. A new BPF_ALU_* flag has to widen it.
No functional change.
Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says:
====================
mlx5-next updates 2026-10-11
* 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
net/mlx5: IFC, Add capability bits for virtual LAG
net/mlx5: Add cap_tx_speed and effective_tx_speed support to IFC
====================
Link: https://patch.msgid.link/20261011113534.802524-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Clarify the netmem, memory provider, page_pool, and skb fragment design
principles in header and code comments:
- Memory providers allocate struct net_iov or struct page, cast them to
netmem_ref, and pass them to page_pool; page_pool, drivers, and the
core stack operate on netmem_ref and must not downcast to page or
net_iov outside dedicated netmem helpers.
- While current memory providers supply struct net_iov, they are not
architecturally restricted to net_iov and may supply page-backed
netmems.
- While current net_iov types are CPU-unreadable, net_iov has no
inherent restrictions and may be readable or unreadable.
- New code should generalize existing limitations as much as possible to
match these design principles.
- Per-provider logic belongs in memory_provider_ops, and per-netmem-type
logic belongs in netmem helpers.
- All frags in an skb must either all be struct page-backed or all
belong to the same memory provider instance; mixing them (including
via coalescing) is not allowed.
Cc: Luigi Rizzo <lrizzo@google.com>
Cc: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Mina Almasry <almasrymina@google.com>
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20261010033630.1171692-2-almasrymina@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The codebase scatters hardcoded minimum page limits across multiple
places. Introduce RING_BUFFER_MIN_NR_PAGES and rb_calculate_nr_pages()
to formalize the requirement of two pages in a ring buffer.
Link: https://patch.msgid.link/20260911193937.602202-4-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Since commit 8a5f63637890 ("ring-buffer: Fix subbuf resize race with
ring buffer readers"), "capacity" refers to the memory available for
events (excluding subbuffer headers) while "size" refers to the raw
allocation. ring_buffer_size() actually calculates this event capacity.
Rename it to ring_buffer_capacity() to align with this convention.
Link: https://patch.msgid.link/20260908090937.838544-2-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Make it possible to specify a trace event filter from the
kernel command line.
Example:
trace_event=syscalls:sys_enter_clock_nanosleep:filter:which_clock==0
Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-7-05396a3fb663@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
ftrace_set_clr_event() modifies its input buffer during parsing.
Before returning to the caller these modifications are undone.
This is restoration is error prone and was forgotten before.
Upcoming changes will also make it more complicated.
Copy the input argument and modify that copy and drop the
restoration logic.
Also mark the input argument as const.
Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-3-05396a3fb663@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Low-level kernel functions are called from many different paths.
When debugging, it is often useful to filter trace events to only
those occurring within a specific call chain.
Add a "within" filter predicate that tests whether a given function
appears in the current call stack at event time. The function name
is resolved to its address range via kallsyms during filter setup;
at runtime, stack_trace_save() captures the call stack and compares
each return address against the stored range.
Example:
echo 'within == "vfs_read"' > events/sched/sched_switch/filter
Only "==" and "!=" operators are supported. The filter depends on
CONFIG_STACKTRACE.
Link: https://patch.msgid.link/20260821233050.335986786@kernel.org
Link: https://patch.msgid.link/20260608145556.94931-1-chenjun102@huawei.com
Signed-off-by: Chen Jun <chenjun102@huawei.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
irq_thread() registers irq_thread_dtor() as exit task_work using a
stack-allocated callback_head. On normal interrupt thread exit, this work
gets cancelled and never runs.
On x86, an abnormal interrupt thread exit (e.g. handler oops) discards the
stack, including the callback_head, while that callback_head is still
pending. By the time exit_task_work() runs, the stack memory formerly
backing callback_head is already clobbered.
irq_thread() <-- on_exit_work allocated
** IRQ handler faults **
oops_end()
rewind_stack_and_make_dead() <-- on_exit_work freed
make_task_dead()
do_exit(SIGSEGV)
...
exit_shm() <-- on_exit_work clobbered
...
exit_task_work() <-- stack use-after-free
exit_shm()+0x30 <-- wild jump to return addr
Thus, a benign threaded IRQ oops (e.g. a NULL pointer deref) is
turned into a wild jump. This is caught by kernel IBT:
** first fault **
Oops: general protection fault, kernel NULL pointer dereference 0x3c0: 0000 [#1] SMP NOPTI
...
** second fault **
Missing ENDBR: exit_shm+0x30/0x1c0
kernel BUG at arch/x86/kernel/cet.c:133!
...
? task_work_run+0x5c/0x90
? do_exit+0x209/0x460
? rewind_stack_and_make_dead+0x16/0x20
...
note: irq/165-AudioDS[1427] exited with irqs disabled
Fixing recursive fault but reboot is needed!
Fix this by storing the callback_head in struct irqaction. The irqaction
is only freed once irq_thread_dtor() finishes.
Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before do_exit()")
Signed-off-by: Richard Patel <ripatel@wii.dev>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261009145842.1616117-3-ripatel@wii.dev
|
|
With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and
only become CQEs when the submitter enters the kernel to wait for events.
For an application that finds out via poll() or epoll on the ring fd when
it is time to do that, io_uring_poll() reports EPOLLIN if local work is
pending.
That only helps if the work is there at the time of the call. When
DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(),
which took care of tasks sleeping in poll() as well. Then polling got a
wait queue of its own, ->poll_wq, and the wake up in
io_req_local_work_add() was replaced by waking the submitter directly.
Since then ->poll_wq is only woken when CQEs are committed, which for
such a ring is done by the very task that is waiting to be told to:
submitter completion
poll(ring_fd)
io_uring_poll() // nothing yet
schedule()
io_req_local_work_add()
// ->cq_wait_nr: nobody waits
// sleeps on
Wake ->poll_wq when the first entry is put on the work list. Like for the
eventfd, that must not be done right away if the work is queued from a
wake up handler, as the chain of wake ups could get back to the wait
queue whose lock is held. Use an RCU callback in that case, with a
reference to the ring.
Fixes: 130bd686d9be ("io_uring: waitqueue-less cq waiting")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-19-c1556f5d7bf5@toxicpanda.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Merge 7.3 fixes to avoid conflicts with future changes merged for the
7.4 kernel.
* io_uring-7.3:
io_uring/cancel: don't spin on local work the task can't run
io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6
io_uring/register: don't exempt disabled rings from task restrictions
io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK
io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK
io_uring: fix task_work add use-after-free with SQPOLL
io_uring/cmd_net: end TX_TIMESTAMP multishot when the CQ is full
io_uring/zcrx: requeue multishot receives stopped by a local resource
io_uring: initialize task context before running the BPF loop
|
|
of_overlay_remove_all() has no in-tree callers.
It is also subtly broken. It passes &ovcs->id to of_overlay_remove(),
which zeroes *ovcs_id once the changeset is reverted, before calling
free_overlay_changeset(). Through the aliased pointer that zeroes
ovcs->id itself, so free_overlay_changeset()'s "ovcs->id > 0" guard is
false and both idr_remove() and list_del() are skipped: the
overlay_changeset is kfree()d while still linked in ovcs_list and
registered in ovcs_idr.
Rather than fix a helper nobody calls, remove it, along with its
!CONFIG_OF_OVERLAY stub and the paragraph documenting it in
overlay-notes.rst and in the zh_CN translation.
ovcs_list itself stays: overlay_removal_is_ok() still walks it to check
that a changeset is topmost.
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/20260901014554.83A8D1F000E9@smtp.kernel.org
Suggested-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/all/20260928182658.GA185307-robh@kernel.org/
Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Link: https://patch.msgid.link/20261014-b4-of-overlay-remove-all-fix-v2-1-cf5ea2cc9dc3@nexthop.ai
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
* 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)
|
|
'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
|
|
Cross-merge networking fixes after downstream PR (net-7.3-rc8).
No conflicts. Adjacent changes:
drivers/net/ethernet/microchip/lan865x/lan865x.c
2a3f6d2a9ac3 ("microchip: lan865x: move setting of netops to fix crash")
15358c2c3dca ("net: ethernet: oa_tc6: return ERR_PTR from oa_tc6_init()")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The existing kerneldoc documentation for URB completion callbacks is
incorrect about the context in which the callbacks occur; it is not
always in_interrupt. State explicitly that a callback may occur in
any context with no guarantees, and likewise for the status of
CPU-local interrupts.
Documentation update only; no code changes.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/de582feb-a0aa-4fc8-9818-890014de32a9@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The vdso/ header namespace is meant for symbols which are usable from
vDSO userspace code. However vdso_update_begin() and vdso_update_end()
are only usable from the kernel.
Move them into a new header in the linux/ namespace. Also rename them to
make clear that they are only for time-related data.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260909-vdso-asm-generic-vsyscall-h-v1-1-63ae856cc659@linutronix.de
|
|
intel_vsec_set_mapping() takes an intel_vsec_device pointer and only
reads the struct device out of it. A caller that has the device but no
intel_vsec_device would have to build one just to make this call.
Pass the struct device instead. TPMI is the only user of this interface
and it is being prepared for enumeration methods other than a PCI VSEC
capability, where no intel_vsec_device exists.
No functional change.
Co-developed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://patch.msgid.link/20261013192935.2243291-3-sathyanarayanan.kuppuswamy@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The physical address of the LINUX_EFI_MEMRESERVE configuration table is
only kept in __initdata, but a kexec loader that runs the incoming
kernel's EFI stub needs it in order to pass the table on, so that the
persistent memory reservations made by this kernel and its predecessors
(e.g., for the GICv3 LPI tables) are carried over.
So move it into struct efi, alongside the addresses of the other EFI
configuration tables that may be passed on in this way.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Implement Thomas's suggestions to constify sysfs kobject attributes.
Cc: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The fwnode describes a global property of the IMSIC interrupt
controller that is equally relevant to external consumers of
imsic_global_config as it is to the imsic_priv itself.
Keeping it in imsic_priv forces the external drivers to access
the private structure rather than using the already exported
imsic_get_global_config() interface.
Moving the fwnode into imsic_global_config makes the public
API self-contained and eliminates the need for callers to
access imsic_priv internals directly.
Signed-off-by: Prajwal N <prajwal.n@oss.qualcomm.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20261002120417.2708979-1-prajwal.n@oss.qualcomm.com
|
|
Some USB serial devices use device-specific flow control to determine
whether write submission may proceed. The generic write path currently
provides no way to pause submission based on driver-specific state. It
also provides no way for a driver to restore its state if URB submission
fails.
Add an optional write_ready() callback to struct usb_serial_driver. Call
it with port->lock held after confirming that data is queued and a write
URB is available. If the callback returns false, stop write processing
and leave the data in the FIFO. The driver must call
usb_serial_generic_write_start() when writes may proceed again.
Add an optional write_rollback() callback for restoring driver-specific
state after usb_submit_urb() fails. Call it with port->lock held after
restoring the generic transmit accounting, and pass it the length of the
prepared transfer.
Drivers which do not provide these callbacks retain the existing generic
write behaviour.
Signed-off-by: Crescent Hsieh <crescentcy.hsieh@moxa.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD
LoongArch KVM changes for v7.4
1. Add separate vmid support.
2. Simplify MSI interrupt injection.
3. Add crash hypercall support.
4. Allow to set pv_feature until vCPU run.
5. Enable HW page table walk automatically in selftests.
|
|
Drivers that register a SPMI sub-device as a platform_driver are
not guaranteed to have a SPMI device as their parent: add a new
helper `spmi_get_parent_spmi_device()` that takes a struct device
and checks if there's a parent, and if that parent is actually a
SPMI device by checking if its device type matches with SPMI: if
so, returns a pointer to the relative struct spmi_device without
incrementing any refcount.
As a note, in the specific case of using this helper to retrieve
a SPMI subdevice's parent, the spmi_subdevice_alloc_and_add()
function does actually call device_add(), which will already take
care of raising the refcount of the associated parent device.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Some devices connected over the SPMI bus may be big, in the sense
that those may be a complex of devices managed by a single chip
over the SPMI bus, reachable through a single SID.
Add new functions aimed at managing sub-devices of a SPMI device
spmi_subdevice_alloc_and_add() and a spmi_subdevice_remove() for
adding a new subdevice and removing it respectively, and also
add their devm_* variants.
The need for such functions comes from the existence of those
complex Power Management ICs (PMICs), which feature one or many
sub-devices, in some cases with these being even addressable on
the chip in form of SPMI register ranges.
Examples of those devices can be found in both Qualcomm platforms
with their PMICs having PON, RTC, SDAM, GPIO controller, and other
sub-devices, and in newer MediaTek platforms showing similar HW
features and a similar layout with those also having many subdevs.
Also, instead of generally exporting symbols, export them with a
new "SPMI" namespace: all users will have to import this namespace
to make use of the newly introduced exports.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Clang's context analysis checker performs alias analysis on expressions
passed to annotations like __acquires(). Clang's alias analysis does not
support container_of(). Convert to_pci_dev() from a macro into an inline
function such that Clang recognizes multiple to_pci_dev() expressions as
identical if the 'dev' argument is the same.
It is on purpose that to_pci_dev() accepts a const pointer and returns a
pointer that is not const. Any other choice, e.g. accepting a non-const
pointer or returning a const pointer, triggers compiler errors in code
that uses the to_pci_dev() macro.
While _Generic() could be used to support const and non-const struct
device pointers in a more elegant way, Clang's alias analysis does not
support _Generic().
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/f147ad227b85439d56183e60e0332547b84441bc.1790360262.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per
job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct
ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command
returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after
the 40-byte header and writes 8 bytes past the end of the buffer.
Let each BSG transport pass its reply buffer size to bsg_setup_queue()
and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full
reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE.
Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20261013132708.1669415-1-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The two parts of '__builtin_choose_expr()' had different arithmetic
expressions. This patch corrects it so that both parts calculate:
COUNT * sizeof(*MEMBER) + __must_be_array(MEMBER)
In practice, '__must_be_array' is meant to assert if 'MEMBER' isn't an
array and return '0' otherwise. However, symmetry is less prone to
subtle errors (and far more satisfying).
Signed-off-by: Bill Wendling <morbo@google.com>
Link: https://patch.msgid.link/20261013203146.387344-1-morbo@google.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI fixes from Bjorn Helgaas:
- Leave ANFE masked on Apple T2 Secure Enclave, which fixes spontaneous
poweroff regressions on MacBookPro16,1 and likely other models with
the T2 caused by new Advisory Non-Fatal Error support (Jason Perlow)
- Move dw-rockchip INTx IRQ setup from rockchip_pcie_host_init(), where
it runs after every reset, to the rockchip_pcie_probe() path to avoid
installing new IRQ handler (which causes INTx IRQs to be lost) and
leaking an IRQ domain on every reset; fixes a regression added this
cycle (Shawn Lin)
* tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: dw-rockchip: Move INTx IRQ setup to probe
PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave
|
|
The "bpf: Use SCEV to widen bounded loops" commit introduced a
second (identical and unnecessary) definition for the
BPF_SCEV_REGS_NUM macro.
Fixes: 088a5477a9bd ("bpf: Avoid widening registers that hinder exact stack-slot tracking")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20261013-scev-minimal-v3-followups-v2-2-6d9d61965486@gmail.com
|
|
fsnotify_destroy_marks() keeps a reference to its current mark while it
drops conn->lock to destroy the mark. This stabilizes the forward-walk
cursor, but does not prevent a new mark from being inserted before it.
For example, an inotify watch re-added after IN_IGNORED sorts before the
old, detached mark for the same group. The walk can miss the replacement
and then detach the entire connector from the object.
The replacement is still on its group's marks_list and, for inotify, in
the watch IDR. The group mutex no longer protects the connector's object
from disappearing. An unprivileged fdinfo read racing the final detach
can consequently call igrab(NULL):
BUG: KASAN: null-ptr-deref in igrab+0x24/0x100
Write of size 4 at addr 0000000000000148
Call Trace:
igrab+0x24/0x100
inotify_show_fdinfo+0x1dc/0x5e0
seq_show+0x397/0x690
Set a DESTROYING flag under conn->lock before starting the walk, and
reject new marks on that connector with -ENOENT. The existing add-mark
error paths undo the temporary group-list entry and the backend's watch
allocation. Do not wait for teardown while holding the group mutex,
which the destroyer needs. Once the old connector is detached, an add
can install a fresh connector as before.
This closes the insertion race for all object types using the common
connector teardown, without changing the mark reference or SRCU lifetime
rules.
Fixes: 6b3f05d24d35 ("fsnotify: Detach mark from object list when last reference is dropped")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
generic_ci_d_hash() and generic_ci_d_compare() read sb->s_encoding and
dereference the unicode map while a pathwalk in rcu mode holds nothing
but rcu_read_lock(). The filesystems that use them, ext4, f2fs and
tmpfs, drop the map with utf8_unload() from ->put_super(), which runs
when the last reference to the mount goes away. A lookup that is still
inside such a filesystem at that point reads a freed map.
With a pathwalk held up in utf8_casefold_hash() while the last reference
to a casefolded tmpfs goes away:
BUG: KASAN: slab-use-after-free in utf8nlookup+0x74c/0x950
Read of size 8 at addr ff110001030fe658 by task walker/98
Call Trace:
<TASK>
utf8nlookup+0x74c/0x950
utf8byte+0x160/0x1560
utf8_casefold_hash+0x167/0x230
generic_ci_d_hash+0xdd/0x1c0
link_path_walk+0x11ad/0x1d30
path_lookupat+0x63/0xb00
filename_lookup+0x1f1/0x5b0
vfs_statx+0xd7/0x3b0
[...]
Allocated by task 94:
__kmalloc_cache_noprof+0x249/0x560
utf8_load+0x4e/0x570
shmem_parse_opt_casefold.isra.0+0x92/0x270
[...]
Freed by task 97:
kfree+0x1db/0x5b0
shmem_put_super+0x72/0x170
generic_shutdown_super+0x14c/0x530
kill_anon_super+0x3a/0x60
deactivate_locked_super+0x9c/0xf0
cleanup_mnt+0x9f/0x130
So far that has been hard to hit. umount(2) waits for a grace period
in namespace_unlock() before it drops the mount, so only a mount whose
last reference goes away elsewhere, like the close of a file or a chdir
out of a lazily unmounted directory, can race a walker. So it is
reachable.
Delay the free until a grace period has passed. The map and the data
table it holds a reference to then outlive any pathwalk that found the
superblock before the mount went away. The reference on the data table
module is dropped from the rcu callback as well. utf8-core is built in
whenever CONFIG_UNICODE is set, so there is no module exit that would
have to wait for the callbacks.
Overlayfs points the s_encoding of an overlay at the map of its first
layer without taking a reference of its own. That stays correct. The
layer is held by the overlay, so its map is dropped only after the
overlay is gone.
Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-6-7446d2d335e6@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
is_child_subreaper, has_child_subreaper, autoreap and, with
CONFIG_POSIX_TIMERS=y, timer_create_restore_ids are 1-bit fields that
share one memory location in struct signal_struct. A store to any of
them is a read-modify-write of the whole word, and three of the stores
run without a common lock:
- PR_SET_CHILD_SUBREAPER writes me->signal->is_child_subreaper with
no lock held.
- propagate_has_child_subreaper(), run by walk_process_tree() from
the same prctl in an ancestor, writes p->signal->has_child_subreaper
of every descendant p under read_lock(&tasklist_lock), which does
not exclude the other writers.
- PR_TIMER_CREATE_RESTORE_IDS writes
current->signal->timer_create_restore_ids with no lock held.
When a process calls prctl(PR_SET_CHILD_SUBREAPER, 1) while an
ancestor's PR_SET_CHILD_SUBREAPER walk visits it, or while another
thread of the same process calls prctl(PR_TIMER_CREATE_RESTORE_IDS),
the read-modify-write sequences interleave and one of the bits is
silently lost:
- If has_child_subreaper is lost, the process's orphaned descendants
are reparented straight to init when it exits: find_new_reaper()
tests father->signal->has_child_subreaper first and never looks for
the ancestor subreaper. The service manager that registered as the
subreaper never gets SIGCHLD for them and cannot wait() on them.
- If is_child_subreaper is lost, the prctl returned 0 but the process
is not a subreaper: orphans of its descendants skip it and are
reparented to the next subreaper up or to init.
PR_GET_CHILD_SUBREAPER reads back 0.
- If timer_create_restore_ids is lost, the prctl returned 0 but
timer_create() does not restore the requested timer ids (or keeps
restoring them after _OFF), and _GET reads back the old value.
Documentation/memory-barriers.txt requires all fields of one bitfield
to be protected by one lock for exactly this reason. No lock is taken
or documented for these flags, and the prctls need no privilege, so any
process can hit the race against its own ancestors or descendants, or
between two of its own threads.
Make is_child_subreaper and has_child_subreaper separate bool members.
Each store then has its own memory location and no read-modify-write
of a neighbour. The readers and their locking are unchanged.
autoreap stays a bit-field and so shares a memory location only with
timer_create_restore_ids. That pair is race-free: autoreap is stored
exactly once, in copy_process() before the new signal_struct is
reachable by any other task, and timer_create_restore_ids is only
stored to the signal_struct of an already running process.
Fixes: 749860ce2427 ("prctl: propagate has_child_subreaper flag to every descendant")
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Link: https://patch.msgid.link/20261011123440.768054-1-nickolai@csail.mit.edu
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 updates for 7.4
* New features
- pKVM state isolation: years after pKVM started being enabled
upstream, we finally get the basics in the form of state
isolation. The vcpu state is now off-limit for the host for
protected VMs.
- pKVM also grows a hypervisor-private memory allocator, allowing it
to deal with sub-page allocation, much like everywhere else.
- pKVM also lands a trace_printk() equivalent, which hopefully will
make debugging a bit easier.
- First shot at annotating portions of the KVM/arm64 code to be
extracted and built on s390. The real fun is yet to come.
- Allow pre-faulting of stage-2 canonical mappings from userspace,
joining x86 and s390 in implementing this feature.
- Add a reverse mapping infrastructure for shadow stage-2,
significantly improving performance when MMU notifiers kick in,
and avoiding full unmap of all shadow tables for this VM.
- Next step of GICv5 enablement, adding support for the IRS block,
and providing both SPI and LPI support. This is the first point
where KVM/arm64 can support an SMP GICv5 guest.
* Improvements
- As a preliminary to eventually enabling CCA, add a bunch of
infrastructure to KVM/arm64, splitting some of the basic
operations into individual backends (normal VM, normal pKVM VM,
protected pKVM VM). This allows CCA to later slot in without
polluting the rest of KVM with its firmware-driven nonsense.
- Make ID registers immutable from the point where a vcpu is able
to run, even if it fails to run. This prevents KVM from sampling
untrusted values.
- Restore some type checking to the EL2 object. KVM/arm64 originally
had some strong type checking between the kernel and the EL2
object, but lost it along the way when the private hypercall
interface was (somewhat pointlessly) converted to SMCCC. Type
checking is back, syscall style, and with added sparse goodies.
- Expand the FFA support to FFA_NOTIFICATION_*, and add some
sanitisation of the protocol that pKVM relays to the "trusted"
runtime.
* Fixes
- Make GICv3 RD assignment more robust to userspace nonsense
- Convert the remaining MMU fault handler backends to
kvm_s2_fault_vma_info and co, fixing a number of bugs in the
process.
- Fix the SError/SEA selftests to be both more robust and less
braindead.
- Fix a smattering of documentation bugs, some of them as a result
of our AI friends spitting out credible assertions based on
non-existing symbols.
- The usual collection of low impact bug fixes (SMCCC, timers, PMU).
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm64 fixes for 7.3, round #2
- Take a reference on the last IRQ loaded into an LR to prevent it
from being freed while running the guest (Marc Zyngier)
- Ensure that the ITS MOVALL command only affects LPIs that were
previously affined to the source redistributor (Marc Zyngier)
- Fix + test for honoring the host's trap configuration when running
non-protected VMs while KVM is in protected mode (Fuad Tabba)
- Use the host stage-1 mapping granularity for VM_PFNMAP mappings at
stage-2 (Mostafa Saleh)
|
|
Defining KVM_MMIO is not flexible enough for multi-KVM systems where one
KVM implements MMIO but others do not. Therefore, remove KVM_MMIO from the
config space and use the macro __KVM_NO_MMIO instead. Define __KVM_NO_MMIO
for KVM/s390 and for HV-only 64-bit Book3s (aka pSeries/sPAPR) configurations.
In particular, for PowerPC configurations:
* KVM_BOOK3S_32 got KVM_MMIO via KVM_BOOK3S_32_HANDLER and KVM_BOOK3S_PR_POSSIBLE
* KVM_BOOK3S_64 got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE if !KVM_BOOK3S_HV_POSSIBLE
* KVM_BOOK3S_64 + KVM_BOOK3S_64_PR got KVM_MMIO via KVM_BOOK3S_PR_POSSIBLE
* likewise for KVM_BOOK3S_64 + KVM_BOOK3S_64_PR + KVM_BOOK3S_64_HV
* KVM_E500V2 and KVM_E500MC directly selected KVM_MMIO
but KVM_BOOK3S_64 + KVM_BOOK3S_64_HV didn't and therefore needs __KVM_NO_MMIO.
coalesced_mmio.c is now always compiled and linked. However, for
architectures/configurations defining __KVM_NO_MMIO this effectively
collapses to an empty object with no mmio code.
No functional changes.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Link: https://patch.msgid.link/20260930173441.66762-4-seiden@linux.ibm.com
[Simplify powerpc condition, add underscores. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
With s390 hosting multiple independent KVM implementations within the
same kernel build (native s390 KVM and arm64 on s390), global Kconfig
selections force both implementations to inherit options that only apply
to one of them.
Replace global Kconfig options which only apply to one KVM
implementation with architecture-specific opt-in defines in the
respective <asm/kvm_host.h>. Only remove Kconfig symbols that would be
different on both s390 KVM implementations
- __KVM_HAVE_INVALID_WAKEUPS (formerly HAVE_KVM_INVALID_WAKEUPS)
- __KVM_HAVE_MSI (formerly HAVE_KVM_MSI)
- __KVM_HAVE_NO_POLL (formerly HAVE_KVM_NO_POLL)
- __KVM_HAVE_READONLY_MEM (formerly HAVE_KVM_READONLY_MEM)
- __KVM_HAVE_VCPU_RUN_PID_CHANGE (formerly HAVE_KVM_VCPU_RUN_PID_CHANGE)
This allows each architecture and guest implementation to configure its
supported capabilities independently in its kvm_host header and eliminates
adding unnecessary fallback stubs across different KVM targets.
Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Link: https://patch.msgid.link/20261013121343.1997112-1-seiden@linux.ibm.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Implement dmabuf backed registered buffers. To register them, the user
should specify IO_REGBUF_TYPE_DMABUF for the regitration and pass the
desired dmabuf fd and a file for which it should be registered.
>From there, it can be used with io_uring read/write requests
IORING_OP_{READ,WRITE}_FIXED) as normal. The requests should be issued
against the file specified during registration, and otherwise they'll be
failed. The user should also be prepared to handle spurious -EAGAIN by
reissuing the request.
Internally, dmabuf registered buffers is an optin feature for io_uring
request opcodes and they should pass a special flag on import to use it.
Suggested-by: David Wei <dw@davidwei.uk>
Suggested-by: Vishal Verma <vishal1.verma@intel.com>
Suggested-by: Tushar Gohad <tushar.gohad@intel.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/4aa230df871ee275536f367087b44ebfebb88cc1.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Add a simple proxy implementation of init_dma_buf_io_ctx() forwarding
the call to a new struct block_device_operations operation. Also reject
dma-buf backed iterators for buffered IO.
Reviewed-by: Christoph Hellwig <hch@lst.de>
[pavel: reject dma-buf without O_DIRECT]
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/c01c4709dc55a12fb0f2fe1ec847b5f1f0c92789.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Premapped buffers don't require a generic bio_vec since these have
already been dma mapped. Repurpose the bi_io_vec space to store dmabuf
maps as they are mutually exclusive.
The bio splitting differs from the normal path because it's already
pre-mapped and for the block layer it's just an offset into the dma-buf.
The actual segmentation is only available to the importer driver and not
the block layer, however, it doesn't contain alignment gaps and we don't
have to check it. For the same reason we can't precisely split by the
number of segments, but we use ->min_seg_shift stored in the map to
calculate the minimum number of bytes a request consisting of
lim->max_segments full segments can cover and split by that. It's
stricter and can add extra splitting. E.g. for a {4K, 4G} segmentation,
the min segment size is 4K, and we'll split it into bios of
(4K * lim->max_segments) bytes each, but it should be good enough for
now to cover the most popular use cases.
Suggested-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/39b964cf7510f42755188563da63d3d5acaf2aa9.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Extend bio_no_advance_iter() iteration to also increment the offset.
It's not currently needed because the currently listed request types
don't have a buffer, but will be useful once we add bios backed by
dma-buf, which don't have a bvec but work with a single range.
Suggested-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/8e5a67c2f84b6df99ff57a7b3bf7b289999e0468.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Introduce a new iterator type for dmabuf maps. The map in an opaque
object with internals and format specific to the subsystem / driver, and
only it can use that subsystem / driver for issuing IO. The task of the
middle layers is to pass the map / iterator further down, maybe doing
basic splitting and length checking. The iterator can only be used by
operations of the file the associated map was created for.
Suggested-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/6aedb1c606f20ae5bd7fa358829966384c6e738f.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The goal is to be able to natively use dma-buf in the read-write / IO
path. This patch adds basic building blocks serving as a glue and API
between drivers and upper layer subsystems providing the uAPI. Later
patches implement it for NVMe raw block devices and expose it to the
user space via io_uring.
There are two main objects. struct dma_buf_io_ctx and struct
dma_buf_io_map. The ctx is used during initial registration and serves
as an interface between the upper layer user like io_uring and to the
importer subsystem / driver. The map represents the actual dma map
established for the target device[s] with dma_buf_map_attachment() and
stored in a device specific format. The context is created via a new
file operation ->init_dma_buf_io_ctx.
The ctx-map separation exists to facilitate map invalidation (see
dma_buf_io_invalidate_mappings()). A ctx can create
multiple maps during its lifetime, but there can only be no more than
one (active) map attached to it. Invalidation drops the active map
if present, and any new I/O request will try to create a new one.
The primary task of dma_buf_io_map is to count requests using it
and wait for their completion when we want to destroy the DMA map.
[un]mapping and any work with dma addresses is delegated to the
importer driver via an ops table stored in the ctx, see struct
dma_buf_io_ops. Only the target driver / subsystem knows about devices
it wants to use the dma-buf with, especially in case of multi-device
filesystems or stacking in the future.
Acked-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Matthew Brost <matthew.brost@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/49e24334953262e85d5616c9afde88c680e4f3a3.1791975048.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Calling rcutree_report_cpu_starting() early during boot can lead to
livelocks with the generic CPU hotplug mechanism if the boot CPU blocks
on an RCU grace period while the CPU being onlined is spinning in
cpuhp_ap_sync_alive().
In preparation for enabling the generic CPU hotplug code on arm64, split
up the trace_hardirqs_off() call during secondary CPU bringup so that we
update lockdep early but defer the tracing updates until after the new
CPU has been registered with RCU, which itself is deferred until after
the early CPU compatibility checks, allowing us to drop the explicit
call to rcutree_report_cpu_dead() entirely.
Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
serial8250_register_8250_port() returns a line number and the other
port operations (serial8250_unregister_port(), serial8250_suspend_port(),
serial8250_resume_port()) accept it. Many drivers then convert the line
back to the port using serial8250_get_port() anyway.
Switch the interface to struct uart_8250_port:
* serial8250_register_8250_port() now returns the registered port, or
an ERR_PTR() on failure.
* serial8250_unregister_port(), serial8250_suspend_port() and
serial8250_resume_port() accept the port.
Convert all users accordingly. Drivers store the port pointer instead
of the line number. Several drivers kept a private struct only to hold
the line (airoha, dfl, em, fsl, ioc3); these are dropped and the port
is stored as drvdata directly.
This also fixes two latent issues:
* For a CIR port, serial8250_register_8250_port() used to return 0.
Callers stored this as the line, so a later unregister/suspend/resume
operated on ttyS0. Now the CIR port itself is returned.
* 8250_acorn checked ports[i] > 0 on removal, so a port registered as
line 0 was never unregistered.
There are no more users of serial8250_get_port() outside of the 8250
core, so drop its EXPORT.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Assisted-by: LLM
Link: https://patch.msgid.link/c59fa203f325e0fe7601ea0fbc0d222c8b37f9eb.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
On a desktop debug kernel (PROVE_LOCKING, KASAN, LOCKDEP_CHAINS_BITS=19)
lockdep switches itself off after about two days of uptime with
"BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!", and locking is not validated
until the next reboot. In the last such boot the pool ran out after 46.6
hours, and a fifth of it, 533509 of 2621431 chain hlocks in 63838 of
344717 chains, had been created by the deferred hrtimer rearm on return
from interrupt.
Make lockdep account that rearm as part of the timer interrupt it
belongs to.
Commit 15dd3a948855
("hrtimer: Push reprogramming timers into the interrupt return path")
moved the reprogramming of the clock event device out of the timer
interrupt into the interrupt return path. On return to kernel mode
irqentry_exit_to_kernel_mode_after_preempt() performs it after
irq_exit_rcu() has already left lockdep's hardirq context. lockdep
therefore records hrtimer_bases.lock and the timekeeper sequence count
as taken by the interrupted context, on top of the locks that context
holds, and every distinct held-lock stack an interrupt hits adds two
lock chains. When the rearm runs from irq_enter_rcu() or
__irq_exit_rcu() it is still inside lockdep's hardirq context, and there
the same acquisitions reuse one pair of chains.
The dependencies recorded on the return path are "lock held with
interrupts enabled -> hrtimer_bases.lock". Such a lock is hardirq-unsafe
and hrtimer_bases.lock is hardirq-safe, so a path in the reverse
direction is already reported by the irq-safety checks without these
edges.
Re-enter lockdep's hardirq context around the rearm on the kernel return
path. The return to user mode path holds no locks and is left alone, as
is the rearm in __schedule(), which runs under the runqueue lock.
With the same kernel tree, configuration and workload, one hour of
uptime including a full kernel build, the chains of this shape, with
hrtimer_bases.lock and optionally the timekeeper sequence count on top
of a held-lock stack outside the scheduler, go from 13266 (96187 chain
hlocks, 15.9% of those in use) to 4. Those 4 come from clock_was_set(),
which takes cpus_read_lock() and each CPU's hrtimer_bases.lock and reads
the clock under it.
Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path")
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20261013071318.33300-1-mikhail.v.gavrilov@gmail.com
|
|
A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM.
It is possible for a process to wait on a shared futex with a different MM
because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED
futex by another process.
This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume
wakeups intended for a newly allocated MM at the same address.
Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID.
Leave private futexes as before to avoid influencing the performance of the
hotpath.
(Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by
setting clear_child_tid such that it points into anonymous memory, which
causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.)
Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()")
Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260929-futex-mmshared-fix-v1-1-262b1ffeb3d0@google.com
Cc: stable@vger.kernel.org
|
|
The RMM specification (DEN0137, B5.5.10 and B5.5.19) defines
RsiHashAlgorithm as an 8-bit enumeration, stored at offset 0x8 of
RsiRealmConfig, with the unused bits of the structure being MBZ.
However, realm_config::hash_algo is declared as unsigned long.
For an RMM that zeroes the unused bits, the wider type gives the same
value. An RMM that only writes the low byte (as TF-RMM currently does)
leaves bytes 1-7 with whatever the guest buffer contained, so a
comparison of the 64-bit field against RSI_HASH_SHA_* can fail. Nothing
in mainline reads the field yet, but the proposed Realm measurement
register support does.
Declare the field as u8 so the guest only depends on the byte the
specification defines. The struct size and the offsets of the other
fields do not change.
Link: https://lore.kernel.org/all/20260413084957.327661-4-sami.mujawar@arm.com/
Fixes: b880a80011f5 ("arm64: rsi: Add RSI definitions")
Signed-off-by: Kohei Enju <enju.kohei@fujitsu.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
MKDEV(ma, mi) evaluates ((ma) << MINORBITS) in whatever type the caller
passes, usually int. For majors >= 2048 (legal: majors go up to 4095) the
result exceeds INT_MAX, which C11 leaves undefined for a signed left
shift; shifting a negative ma is undefined regardless of the major's
value. In practice, on the compilers and two's complement targets the
kernel supports, both cases wrap to the intended bit pattern; this patch
makes the macro well defined regardless by casting the major to dev_t
before shifting. For major and minor numbers in range, the device number
it produces is unchanged.
isofs feeds the Rock Ridge 'PN' entry's dev_high and dev_low into MKDEV()
while holding them in int variables (fs/isofs/rock.c), so a crafted image
can drive this exact shift. Fixing the macro covers every caller instead
of just that one.
Link: https://lore.kernel.org/20260927224958.508964-1-matthias.goergens@gmail.com
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
nmi_panic() used to accept variable arguments until commit ebc41f20d77f
("panic: change nmi_panic from macro to function") flattened it to a final
message string. vpanic() did not exist back then, so the function had to
format through panic("%s", msg).
Bring the variable arguments back and format with vpanic() directly.
The next patch makes nmi_panic() try the panic_force_cpu= redirect
before claiming panic_cpu. panic_try_force_cpu() needs to print the
message but it is used also by panic() which accepts variable argument
list. The string could be formatted only when a CPU gets assigned to
process the redirection. Otherwise, there might be a race when writing
to the `panic_force_buf`.
No current caller passes a string with format specifiers. The closest one
is hpwdt_pretimeout(), which builds panic_msg with hex_byte_pack() and has
only two variants, both plain strings. But the new __printf() annotation
on nmi_panic() would warn with -Wformat-security there because the buffer
is passed directly as the format argument, so switch it to nmi_panic(regs,
"%s", panic_msg).
[pmladek@suse.com: changelog fix]
Link: https://lore.kernel.org/arJxFybmtD7OBIcL@pathway.suse.cz
Link: https://lore.kernel.org/20260916182957.7788-5-brads@mainlining.org
Signed-off-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Suggested-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Guenetr Roeck <linux@roeck-us.net>
Cc: Sashiko <sashiko-bot@kernel.org>
Cc: Wang Jinchao <wangjinchao600@gmail.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: <stable@vger.kernel.org>
|
