| Age | Commit message (Collapse) | Author |
|---|
|
API kvm_vcpu_ioctl_interrupt() is mainly to used to deliver interrupt
from user mode, and internal APIs kvm_queue_irq() and kvm_dequeue_irq()
are used in kernel mode.
Also move IPI inject and ack within lock protection to avoid contention
in ipi_set() and ipi_clear().
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Variable vector[] is declared on stack in function dmsintc_inject_irq()
and sometimes it is used without initialized. Here fix this issue.
Cc: stable@vger.kernel.org
Fixes: 03de5eecb0f0 ("LoongArch: KVM: Add DMSINTC inject msi to vCPU")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
When IPI address is not aligned with its access size, it should return
directly in read/write operations, rather than only print a message with
WARN_ON_ONCE(). The method is the same with in kernel EIOINTC and PCHPIC
operations.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
With IOCSR instruction emulation in function kvm_emu_iocsr(), possible
size combination is 1/2/4/8 and no other combinations. Here remove the
old default case and replace the default case with 8 in read_mailbox()
and write_mailbox().
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In function kvm_make_vcpu_request(), it will send IPI to physical CPU
when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function
kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set.
Otherwise IPI will send to wrong old physical CPU where vCPU is running.
Cc: stable@vger.kernel.org
Fixes: 2fc3bd86db4b ("LoongArch: KVM: Implement basic vcpu interfaces")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
kvm_complete_mmio_read() already advances the guest PC via update_pc().
The explicit update_pc() call right after it advances the PC a second
time, so PC moves forward by 8 bytes instead of 4, and the instruction
following the MMIO read is silently skipped.
The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run()
calls kvm_complete_mmio_read() only once, and the MMIO write fast path
advances the PC exactly once as well.
Here remove the redundant update_pc() so the kernel MMIO read fast path
advances the PC by a single instruction.
Cc: stable@vger.kernel.org
Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
A guest can write CSR.TCFG with the periodic bit set but a period value
of zero. When kvm_restore_timer() later enters the periodic branch,
period = cfg & CSR_TCFG_VAL evaluates to 0, causing (delta % period) to
trigger a division by zero and crash the host kernel.
Clamp the period to 1 to avoid the panic.
Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
kvm_restore_timer() rebuilds the remaining timer countdown value from
vcpu->arch.expire, which is host-internal and is not part of the
migrated vCPU state. On the migration destination it is still 0, so for
a one-shot timer that has not expired yet the computed delta is 0 and
write_gcsr_timertick(0) injects the timer interrupt immediately instead
of after the remaining time.
The expired one-shot case (TVAL = -1) is already handled earlier. When
expire has not been set (i.e. on the migration destination), reload the
remaining countdown value from the migrated TVAL. This covers both one-
shot and periodic timers. The regular preempt/resume path on the source,
where expire is valid, is unchanged.
Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Suggested-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Several LoongArch KVM features are fully implemented but were never
reported through their standard KVM_CHECK_EXTENSION probes, so userspace
cannot discover them. Advertise the ones that already work so as to have
a real consumer:
- KVM_CAP_VCPU_ATTRIBUTES: per-vCPU device-attribute ioctls are
implemented (CPUCFG, PVTIME control); advertise the discovery cap.
- KVM_CAP_STEAL_TIME: steal time works end-to-end (host-side record
plus guest-side paravirt), the probe returns kvm_pvtime_supported().
This doesn't add new functionalities; it only makes existing features
discoverable via the standard probe.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
|
|
elan-i2c-ids.h only needs struct acpi_device_id from the ACPI
device ID definitions. The MODULE_DEVICE_TABLE() user already includes
<linux/module.h>.
Include <linux/device-id/acpi.h> instead of the broader
<linux/mod_devicetable.h> header.
Assisted-by: Codex:GPT-5
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
Link: https://patch.msgid.link/20260809142928.4031270-1-xialonglong2025@163.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Key slots are released through a kref and the existing release path
frees the AEAD transforms from an RCU callback. That is not safe for all
crypto implementations: crypto_free_aead can sleep, for example when an
async or hardware implementation has teardown work to complete.
Use queue_rcu_work for key-slot release. This keeps the RCU grace period
needed by lockless key-slot readers, but runs the actual crypto teardown
from workqueue context where sleeping is allowed. Once the rcu_work
callback runs, pre-existing RCU readers are gone, and the final kref put
already proves that no transform user remains, so the worker can release
the AEAD transforms and free the slot directly.
The previous patch drains ovpn_wq during module exit, so queued key-slot
teardown work cannot outlive module text.
Fixes: 8534731dbf2d ("ovpn: implement packet processing")
Signed-off-by: Ralf Lici <ralf@mandelbit.com>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
ovpn queues several work items whose callbacks execute module text.
These works currently run on the global system workqueues, so module
exit has no driver-owned drain point that guarantees the callbacks have
fully returned before the module text can be freed.
Object references protect the objects used by the callbacks, but they do
not prove that a workqueue function has returned. In particular, a
worker can drop the final reference that unblocks device teardown while
it is still executing ovpn code.
Add a module-owned workqueue and queue all ovpn work items on it. During
module exit, unregister rtnl and netlink first, flush the workqueue so
ordinary ovpn workers finish, run the final RCU barrier, and destroy the
workqueue last. This keeps the workqueue available for cleanup work
queued from RCU callbacks, while ensuring no ovpn work item can outlive
the module text.
The per-device delayed keepalive work remains explicitly disabled during
netdev teardown (disable_delayed_work_sync in ndo_uninit), since
flush_workqueue does not flush delayed work that is still only pending
on its timer.
Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism")
Fixes: 11851cbd60ea ("ovpn: implement TCP transport")
Signed-off-by: Ralf Lici <ralf@mandelbit.com>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix use-after-free in eventfs_remove_rec()
The freeing of the eventfs_inode children used list_for_each_entry()
where the child is freed via srcu, but there's still a chance that it
gets freed. It should be using list_for_each_entry_safe().
- Fix eventfs_inode SRCU use of list in freeing
The iterator uses an SRCU protected list walk on the eventfs inodes.
The eventfs inode uses its "list" field in a union with the RCU list
head. When the inode gets added to the SRCU list it immediately
corrupts the list pointer and can cause an issue with the iterator.
Move the RCU list head to be shared with the children list head which
allows the iterator to check the parent inode if is freed before
referencing the child. Have the iterator check the parent "is_freed"
field and break out if it is set. Also add memory barriers to make
sure the ordering is correct.
- Fix various RCU synchronization issues with direct_functions
Updates to direct_functions have some missing RCU protection and
synchronization. Restructure the code a bit to make sure updates to
the direct_functions are protected.
- Remove an unneeded comma from a scope_guard()
There's a spurious comma in a scope_guard(). Remove it.
- Fix race in per CPU buffer swap in the ring buffer
When a per CPU buffer swap happens, it must make sure that it doesn't
occur while a writer is active. Instead it returns an -EBUSY. But
there's a small race window when a writer moves from one sub-buffer
to the next that it resets the "committing" counter. If a swap
happens at that moment, the buffer used for the commit of an event
will not match the buffer the event is actually on. Instead of using
the "committing" counter, use the recursive detection counter that
does not get reset when the writer crosses sub-buffers.
- Fix off-by-one in ftrace_free_mem()
The function ftrace_free_mem() gets an "end_ptr" as a parameter that
is exclusive to the rang to be freed. But its value is used to search
for the records that expects an inclusive value. Subtract one from
the parameter to convert it to an inclusive range.
- Disable resizing of the ring buffer for persistent buffers
Resizing the persistent buffer has undefined behavior. Prevent it
from being resized.
- Disable changing ring buffer subbuf order when resizing is disabled
The ring buffer subbuffer order can not be changed during resizing.
Use that instead of just checking if the buffer is mapped as mapped
buffers also have resizing disabled.
- Initialize subbuf_order of reader pages when they are created
In rb_allocate_cpu_buffer() the bpage->order is not updated to the
current subbuf_order leaving it as zero. This value is used when the
page is freed.
- Fix test_ringbuffer() to test for ERR_PTR before calling
kthread_stop()
The rb_threads[] array is assigned the output of kthread_run_on_cpu()
which could return an ERR_PTR. At the end of the test, all threads in
the array are cleaned up by kthread_stop() passing in the value in
the array if it isn't zero. But if the array contains an ERR_PTR,
kthread_stop() will not be able to handle it properly.
* tag 'trace-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
ring-buffer: Fix crash passing ERR_PTR to kthread_stop()
ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()
ring-buffer: Prevent subbuf order change when resizing is disabled
ring-buffer: Prevent resizing of persistent ring buffer
ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()
ring-buffer: Use current_context for safe per-CPU buffer swap
ftrace: Drop extra comma in trace_buffered_event_enable
ftrace: Protect direct_functions in update_ftrace_direct_mod
ftrace: Protect direct_functions in update_ftrace_direct_del
ftrace: Protect direct_functions in ftrace_find_rec_direct
eventfs: Use children field for rcu head and add memory barriers
eventfs: Fix use-after-free in eventfs_remove_rec()
|
|
Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
documentation.
The ioctl exposes host processor compatibility modes supported for
nested KVM guests on PowerPC systems. The documentation covers error
code descriptions including E2BIG for forward compatibility,
KVM_PPC_COMPAT_CAPS_SIZE_VER0 as the minimum size floor, the rationale
for rejecting non-zero reserved fields to prevent ABI ambiguity, bit
numbering clarification for IBM MSB-0 convention, and KVM-specific
capability bit constants.
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-5-amachhiw@linux.ibm.com
|
|
Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
hypervisor (L0), the guest runs with the expected processor
compatibility level. However, when booting a nested KVM guest (L2)
inside the L1, QEMU derives the CPU model from the raw host PVR and
attempts to run the nested guest at that level, instead of honoring the
compatibility mode of the L1.
Extend host CPU compatibility capability reporting to support nested
virtualization on PowerNV systems (PAPR nested API v1).
For nested API v2 (PowerVM), compatibility capabilities are served from
the cached nested_capabilities value (populated at module init via
kvmhv_nested_init() using the H_GUEST_GET_CAPABILITIES hcall). This
information is not available on PowerNV systems.
For nested API v1, derive the compatibility capabilities from the L1
guest by reading the "cpu-version" property from the device tree, which
reflects the effective (logical) processor compatibility level. Map this
value to the corresponding compatibility capability bitmap using
KVM-specific constants.
The mapping is cumulative: a system running at a given compatibility
level is assumed to also support older generations down the supported
chain. Note that unlike KVM on PowerVM (nested API v2), KVM on PowerNV
currently does not strictly enforce older generation compatibility modes
for nested guests - the reported capabilities reflect what the host CPU
can present, not what the hypervisor independently validates.
Introduce a helper kvmppc_map_compat_capabilities() to translate CPU
version values into KVM_PPC_COMPAT_CAP bits using a fallthrough switch,
and integrate it into kvmppc_get_compat_caps(). The implementation
applies masking to ensure only supported processor modes are exposed.
This allows userspace to query host CPU compatibility modes on both
KVM on PowerVM and on PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS
ioctl.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-4-amachhiw@linux.ibm.com
|
|
PowerVM
On POWER systems, the host CPU may run in a compatibility mode (e.g., a
Power11 processor operating in Power10 compatibility mode). In such
cases, the effective CPU level exposed to guests differs from the
physical processor generation.
When running nested KVM guests, QEMU derives the host CPU type using
mfpvr(), which reflects the physical processor version. This can result
in a mismatch between the CPU model selected by QEMU and the
compatibility mode enforced by the host, leading to guest boot failures.
For example, booting a nested guest on a Power11 LPAR configured in
Power10 compatibility mode fails with:
KVM-NESTEDv2: couldn't set guest wide elements
[..KVM reg dump..]
This occurs because QEMU selects a CPU model corresponding to the
physical processor (via mfpvr()), while the host operates in a lower
compatibility mode. As a result, KVM rejects the requested compatibility
level during guest initialization.
On pseries nestedv2 systems, add support for retrieving host CPU
compatibility capabilities for nested guests on PowerVM. The capability
bitmap reflects the processor modes negotiated between the Power
hypervisor (L0) and the host partition (L1) via the
H_GUEST_GET_CAPABILITIES hcall, but is retrieved from the cached
nested_capabilities value populated during module initialization,
avoiding repeated hypervisor calls. A WARN_ON_ONCE() flags the
unexpected case where nested_capabilities is zero on a nestedv2 system.
The implementation defines KVM-specific capability constants
(KVM_PPC_COMPAT_CAP_POWER9/10/11), masks unsupported bits, and exposes
the result through the KVM_PPC_GET_COMPAT_CAPS ioctl.
Hook the implementation into the Book3S HV kvmppc_ops so that it can be
invoked by the generic KVM ioctl handling code.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-3-amachhiw@linux.ibm.com
|
|
Introduce a new capability and ioctl to expose CPU compatibility modes
supported by the host processor for nested guests.
On IBM POWER systems, newer processor generations (N) can operate in
compatibility modes corresponding to earlier generations, like (N-1) and
(N-2). This is particularly relevant for nested virtualization, where
nested KVM guests may need to run with a specific processor compatibility
level.
Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
the compatibility modes supported by the host in respective bit numbers,
allowing userspace (e.g., QEMU) to select an appropriate compatibility
level when configuring nested KVM guests.
The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
CPU compatibility capabilities via a PowerPC-specific backend
implementation when available.
The struct kvm_ppc_compat_caps places the 'size' field first so it can
be read alone via get_user() before copy_struct_from_user() is called,
avoiding pointer arithmetic to locate the size field.
The ioctl is defined using _IO so the ioctl number remains stable even if
the struct grows in future versions. It uses copy_struct_from_user() and
copy_struct_to_user() to provide forward- and backward-compatible
extensibility: older userspace passing a smaller struct to a newer kernel
gets zero-padded trailing fields. Newer userspace passing a larger struct to
an older kernel (usize > ksize) succeeds if trailing bytes are zero (the
kernel reports back min(usize, ksize) as the filled size); if trailing bytes
are non-zero, the kernel writes back ksize into host_caps.size and returns
-E2BIG so userspace can retry with the correct size.
KVM_PPC_COMPAT_CAPS_SIZE_VER0 is defined as a frozen integer constant
(24) marking the size of the initial struct version, used as the
minimum floor for size field validation, similar to other versioned
struct interfaces in the kernel.
The 'flags' field is reserved for future use. The kernel rejects any
call where flags is non-zero with -EINVAL, preventing garbage values
from being baked into ABI permanently.
The ioctl returns appropriate error codes: E2BIG if usize exceeds
PAGE_SIZE, or if new userspace provides a larger struct with non-zero
trailing bytes (with ksize written back into host_caps.size for the
retry); EINVAL for an invalid size or non-zero reserved fields; EFAULT
for failed copy operations; and ENOTTY if the backend doesn't implement
get_compat_caps.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-2-amachhiw@linux.ibm.com
|
|
Replace devm_kasprintf() with dev_name() for the chip label. dev_name()
returns a stable pointer to the device name, so the separate allocation
and -ENOMEM check can be dropped.
Using dev_name() seems to be common for GPIO labels.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-9-rosenp@gmail.com
|
|
Shifting a 32-bit unsigned integer by 32 or more places is undefined
behavior in C. GPIO_MASK2 computes its shift amount as (gpio) * 2, and
for pins 16-31 in the OSRH/TSRH bank this yields shifts of 32-62.
While this happens to work on PowerPC because slw masks the shift count
to the low 5 bits, compilers performing value-range propagation may
assume the else branch is unreachable and optimize it away, or may
evaluate the shift as zero on other architectures via COMPILE_TEST.
Mask gpio to the 16-pin bank index so the shift stays within [0, 30].
The registers are banked (OSRL/TSRL for gpio 0-15, OSRH/TSRH for
gpio 16-31) with an identical 2-bit-per-pin layout from MSB to LSB,
so masking to the within-bank index preserves the intended behavior.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-8-rosenp@gmail.com
|
|
Replace PPC-specific clrbits32()/setbits32() with local helpers using
ioread32be()/iowrite32be() which are equivalent on PPC since commit
894fa235eb4c ("powerpc: inline iomap accessors").
Add COMPILE_TEST as a result to increase compile coverage.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-7-rosenp@gmail.com
|
|
Use gpio_generic_chip_init() to set up the PPC44x GPIO chip
instead of open-coding the basic get, set, locking and state handling.
Keep the PPC44x-specific direction callbacks because they still need to
program ODR and the OSR/TSR registers around the generic data and
direction registers.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-6-rosenp@gmail.com
|
|
Map the PPC44x GPIO register block through the platform device
resource instead of reparsing the firmware node directly.
The GPIO node now probes as a platform device, so use the
platform helper to keep resource handling aligned with the converted
driver model and to report mapping failures with the platform device
context.
Move ioremap up in order to avoid doing extra work in case of
-EPROBE_DEFER.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-5-rosenp@gmail.com
|
|
Replace the open-coded arch initcall registration with
module_platform_driver(). The initcall level changes from
arch_initcall to device_initcall, which is safe since the
driver no longer needs architecture-specific ordering.
Added MODULE info as a result, otherwise these warnings appear
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ppc4xx.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-ppc4xx.o
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-4-rosenp@gmail.com
|
|
The kernel lost support for 4xx platforms and now only supports 44x.
Since this driver is being moved to drivers/gpio/ , take the opportunity
to modernize the name.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-3-rosenp@gmail.com
|
|
Move the ppc4xx gpio driver out of arch/powerpc/platforms/44x/ into
drivers/gpio/gpio-ppc44x.c. The driver has no architecture-specific
dependencies and follows the same pattern as other PowerPC GPIO
drivers already in drivers/gpio/ (e.g. gpio-mpc8xxx, gpio-mpc5200).
- Renamed Kconfig symbol from PPC4xx_GPIO to GPIO_PPC44X
- Updated ppc44x_defconfig and warp_defconfig to use the new symbol
- Marked the new option as tristate (was bool) since the driver
supports module build via module_platform_driver()
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-2-rosenp@gmail.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- Fix potential uninitialized memory reads and buffer overflows from
malformed zcrypt CCA and EP11 requests by properly validating lengths
and payloads
- Fix possible out of bounds accesses in zcrypt EP11 domain handling by
replacing fixed payload layout assumptions with parsing ASN.1 fields
with bounds checks
- Fix zcrypt CCA and EP11 request and reply buffer allocations missing
required 4-byte padding, and scrub the full allocation on release
- Fix zcrypt CCA and EP11 messages leaking up to 3 uninitialized bytes
of memory by zeroing trailing alignment padding
* tag 's390-7.2-7' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/zcrypt: Pad trailing CCA or EP11 message with zeros
s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
s390/zcrypt: Improve EP11 CPRB length and overflow checks
s390/zcrypt: Improve CCA CPRB length and overflow checks
s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code
|
|
The ahci-mvebu driver and libahci_platform request three supplies
on SATA controller and port nodes:
- ahci-supply (controller power)
- phy-supply (PHY power)
- target-supply (disk power per port)
Without them the regulator core prints notices at boot, e.g.:
supply ahci not found, using dummy regulator
supply phy not found, using dummy regulator
supply target not found, using dummy regulator
The SATA controller and PHY inside the Armada 388 SoC are powered
by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD
rail. Wire the existing fixed regulators accordingly.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The pca953x driver requests a 'vcc' supply, producing:
pca953x 0-0020: supply vcc not found, using dummy regulator
The PCA9655 (PCA9555-compatible) expander is powered by the same
always-on 3.3V rail as the other I2C devices on the bus. Add
vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The at24 driver requests a 'vcc' supply for the EEPROM, producing
'supply vcc not found, using dummy regulator' at boot when the
property is missing.
The EEPROM sits on the Helios 4 and is powered by the
same always-on 3.3V rail used by other on-board I2C devices.
Add vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
After commit 00e6d608fe80b0f6 ("arm64: dts: marvell: armada-37xx: swap
PHYs' order in USB3 controller node") swapped USB3 PHY order, USB
initialization breaks on Turris MOX.
This regression was exposed by commit 91ddf6f722084383 ("phy: marvell:
mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access") which
made USB2 devices not work at all.
Fix the issue by explicitly adding all USB3 PHYs and PHY names to
Turris MOX device-tree.
Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Tomáš Macholda <tomas.macholda@nic.cz>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The BIOS of the F+ FLAPTOP r laptop (Realtek ALC897, SSID 1e63:6d9a)
declares only pin 0x1b, the headphone output of the 3.5 mm combo jack.
Every other external pin is left at 0x411111f0, so the headset mic pin
0x19 is never parsed and no headset mic input exists. The pin is wired
on this board - retasking it makes the headset mic record.
Reuse ALC897_FIXUP_HP_HSMIC_VERB, which already sets the pin config this
machine needs: 0x19 as a headset mic without its own presence detect.
Only 0x1b reports jack presence here, so a mic pin with presence detect
would leave the driver in auto-mic mode waiting for an event that never
arrives.
Without the quirk the generic parser retasks the lone headphone pin as
an input instead. That surfaces as a "Headphone Mic" input which records
only the internal mic bleed, so the headset mic appears present but dead.
Tested on ALT Linux, kernel 6.12, by recording a CTIA headset mic on the
combo jack with the internal mic as a reference.
ALSA info before the patch:
https://alsa-project.org/db/?f=18363eddea933baee100c9bf461d0e5cf74c8de2
ALSA info after the patch:
https://alsa-project.org/db/?f=48ae2cd7aaf1eb0f24639ce83cd38cfd93b25f76
Cc: stable@vger.kernel.org # 6.12.x
Signed-off-by: Ajrat Makhmutov <rauty@altlinux.org>
Link: https://patch.msgid.link/20260808185500.2564948-1-rauty@altlinux.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
set_sample_rate_v2v3() returns early when the clock already reports the
requested rate:
prev_rate = get_sample_rate_v2v3(chip, fmt->iface,
fmt->altsetting, clock);
if (prev_rate == rate)
goto validation;
A device advertising exactly one sample rate always takes this branch, so
it never receives a SET_CUR for CS_SAM_FREQ_CONTROL at all.
The Mackie DLZ Creator XS (0a73:003a, 14 in / 4 out, 48 kHz only) requires
that write. Without it the device drops off the USB bus roughly 0.2-1.8 s
into any stream, clearing its port CONNECTION bit; captured audio is
byte-correct until the instant it vanishes.
USBPcap traces of a cold-booted device on Windows show SET_CUR 48000 issued
unconditionally on every stream start, followed by clean streaming. The
device is otherwise driven with plain class-compliant UAC2 - it also works
on iOS, which cannot load a vendor driver - so no vendor-specific
initialization is involved.
The device is self-powered, so the resulting state survives a USB replug:
initializing it on any host that issues the write leaves it working on
Linux until it is power-cycled, which made the failure look intermittent.
Add a quirk flag rather than dropping the early exit, since the opposite
requirement also exists in-tree: QUIRK_FLAG_FIXED_RATE suppresses rate
setting for single-rate devices (JBL Quantum610/810). The two behaviors
are device-dependent and cannot both be the default.
A/B on identically cold-booted hardware, same kernel, same port, repeated
twice:
without the flag device dropped after 5-6 s, then again after 3-4 s
with the flag 20 s playback followed by 20 s of 14-channel capture,
960000 frames, zero re-enumerations
This change was developed with an AI coding assistant. The assistant did
the trace analysis that located the bug and wrote the patch and this
changelog; the hardware testing, the cold-boot cycles and the decision to
submit were the author's. Several earlier hypotheses it proposed - URB
queue depth, isochronous packet under-allocation, endpoint start ordering -
were disproven by measurement before this one.
The bug was located with usbmon on Linux and USBPcap on Windows, by
diffing an enumeration capture of a cold-booted device on each host.
Verified on physical hardware by the A/B above.
Assisted-by: Claude-Code:claude-opus-5
Signed-off-by: JJ Macalinao <jj@macalinao.org>
Link: https://patch.msgid.link/20260808172726.1107550-1-jj@macalinao.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In test_ringbuffer()'s out_free cleanup loop, the check
`!rb_threads[cpu]` only catches NULL entries and misses entries that
hold an ERR_PTR.
rb_threads[] is static, so unassigned slots are NULL. But when
kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or
-EINTR) in rb_threads[cpu] before the creation loop jumps to out_free.
That entry is non-NULL, so the old `!ptr` check does not break, and the
cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop()
then dereferences the bogus pointer, crashing the kernel during the
late_initcall self-test.
crash logs:
BUG: kernel NULL pointer dereference, address: 000000000000001c
Oops: 0002 [#1] SMP NOPTI
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy)
RIP: 0010:kthread_stop+0x2e/0x220
RBX: fffffffffffffff4
CR2: 000000000000001c
Call Trace:
<TASK>
test_ringbuffer+0x1ec/0x650
do_one_initcall+0x6c/0x2c0
kernel_init_freeable+0x21d/0x420
kernel_init+0x15/0x1c0
ret_from_fork+0x21b/0x320
</TASK>
Kernel panic - not syncing: Fatal exception
Cc: stable@vger.kernel.org
Fixes: 64ed3a049e3e ("ring-buffer: make use of the helper function kthread_run_on_cpu()")
Link: https://patch.msgid.link/20260807154145.2846521-2-sh_def@163.com
Signed-off-by: Hui Su <sh_def@163.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0.
This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if
when freed: free_buffer_page() relies on this value. Align the value
with the actual allocation size (buffer::subbuf_order).
Cc: stable@vger.kernel.org
Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page")
Link: https://patch.msgid.link/20260806211306.3704194-4-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Because ring_buffer_subbuf_order_set() frees buffer pages, we can't
allow it when resizing is disabled. A non-consuming reader is at risk of
use-after-free (rb_advance_iter()).
Return -EBUSY on resize_disabled, matching ring_buffer_resize()
behaviour.
Cc: stable@vger.kernel.org
Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page")
Link: https://patch.msgid.link/20260806211306.3704194-3-vdonnefort@google.com
Reported-by: syzbot+e0cc44465d6bae735679@syzkaller.appspotmail.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Dynamically resizing a persistent ring buffer is not possible. Disable
the feature.
Cc: stable@vger.kernel.org
Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()")
Link: https://patch.msgid.link/20260806211306.3704194-2-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
When a module's init text is freed, do_init_module() calls
ftrace_free_mem() with a half-open [start, end) range. However the
ftrace_cmp_recs() comparator treats the upper bound as inclusive, as all
its other users do, passing 'ip + size - 1'. So ftrace_free_mem() can
delete a record sitting exactly at 'end', which is outside the freed
range.
For a kernel without CFI or IBT, the first record of a function is at
the function start, which for the first function in a module is also the
base of its text allocation. As the module allocator packs its regions,
that address is often the 'end' passed by a neighboring module's
do_init_module(), causing the first function's ftrace location to get
disabled, preventing an attempt to livepatch it:
livepatch: failed to find location for function 'pcspkr_probe'
Convert the exclusive end to the inclusive 'end - 1' the comparator
expects, and return early for an empty range to avoid the subtraction
from underflowing when the init text size is zero.
Cc: stable@vger.kernel.org
Fixes: 42c269c88dc1 ("ftrace: Allow for function tracing to record init functions on boot up")
Link: https://patch.msgid.link/1b5ccfa8095bdb1277f84af1c2c2e2205aca03ae.1785992188.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
The ring_buffer_swap_cpu() function currently checks the per-CPU
committing counter to determine if a buffer is actively being written to
before performing the swap. However, there exists a race window where
this check can be bypassed:
ring_buffer_lock_reserve
cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a
rb_reserve_next_event
rb_start_commit // inc committing
if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...}
__rb_reserve_next
rb_move_tail
rb_end_commit(cpu_buffer); // dec committing => 0
/* interrupt hits here, successfully swaps! */
local_inc(&cpu_buffer->committing);
ring_buffer_unlock_commit
cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b
rb_commit
rb_end_commit
RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))
// triggers warning
The committing counter can temporarily drop to 0 during a single write
operation (within rb_move_tail), creating a window where swap can
succeed even though the write is still in progress. This leads to
inconsistent buffer state and triggers the RB_WARN_ON in rb_commit().
Replace the committing counter check with current_context checks, which
are set at the entry of ring_buffer_lock_reserve() and remain valid
throughout the entire write operation, providing a reliable indicator of
buffer busy state during swap.
Cc: stable@vger.kernel.org
Fixes: 4239c38fe0b3 ("ring-buffer: Process commits whenever moving to a new page.")
Link: https://patch.msgid.link/20260803005640.2445666-2-wutengda@huaweicloud.com
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
arm64: tegra: Device tree changes for v7.3-rc1
This contains a new device tree for the Lenove ThinkEdge SE70 Edge
Client device as well as a number of fixes and cleanups for Tegra234 and
Tegra194. Tegra264 sees a number of additions to enable more features.
* tag 'tegra-for-7.3-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: (1469 commits)
arm64: tegra: Correct Tegra234 p3740 interrupt flags
arm64: tegra: Correct Tegra234 p3737 interrupt flags
arm64: tegra: Correct Tegra194 p2972 interrupt flags
arm64: tegra: Drop CPU masks from GICv3 PPI interrupts
arm64: tegra: Add Lenovo ThinkEdge SE70 device tree
arm64: tegra: Add pinctrl nodes for Tegra264
arm64: tegra: Fix CMDQV interrupt type on Tegra264
arm64: tegra: Properly sort devices on Tegra264
arm64: tegra: Add GTE nodes for Tegra264
arm64: tegra: Add Host1x and VIC on Tegra264
arm64: tegra: Populate CPU and L2 cache nodes on Tegra264
arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
Linux 7.2-rc5
super: fix emergency thaw deadlock on frozen block devices
tracing: perf: Fix stale head for perf syscall tracing
ftrace: Add global mutex to serialize trace_parser access
tracing: Delay module ref count for "enable_event" trigger
tracing: Fix use-after-free freeing trigger private data
bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()
tracing: Fix context switch counter truncation
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
dt-bindings: Changes for v7.3-rc1
This contains a few fixes for interrupt types and email addresses as
well as the addition of a compatible string for the Lenovo ThinkEdge
SE70 Edge Client.
* tag 'tegra-for-7.3-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
dt-bindings: gpu: host1x: Fix email address
dt-bindings: iommu: Fix interrupt type in example
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Ingo Molnar:
- Fix MCE CMCI discovery initialization ordering bug (Breno Leitao)
* tag 'x86-urgent-2026-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Set up the polling timer before CMCI discovery
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull futex fix from Ingo Molnar:
- Fix race in futex_pivot_pending() during private hash resize
that can cause stuck tasks (Yao Kai)
* tag 'locking-urgent-2026-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
futex: Fix race in futex_pivot_pending() during private hash resize
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt fixes from Greg KH:
"Here are some small USB and Thunderbolt driver fixes for 7.2-rc7 that
resolve some reported issues. Included in here are:
- new quirk for some broken USB devices
- thunderbolt device fixes for reported issues
- usb gadget driver fix
- usb atm driver fix
- xhci driver fixes.
- other minor USB driver fixes
All of these have been in linux-next this week with no reported
issues"
* tag 'usb-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: xhci: use BIT_ULL for CRCR bits to fix incorrect 64bit mask
usb: quirks: Add ShanWan gamepad to quirk list
usb: hub: Split announce_device() to log device identity before enumeration
usb: core: Add quirk for 255-bytes initial config read
usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()
usb: misc: usbio: check ibuf_len against rxbuf_len in bulk msg
usb: gadget: f_ncm: Use unsigned int for ndp_index
usb: cdnsp: fix incorrect endian conversions for APB timeout register
thunderbolt: Initialize ->domain_released completion before it is being used
thunderbolt: icm: Preserve USB4 proxy data-valid bit
thunderbolt: Bound the DROM dual link port number before indexing sw->ports
thunderbolt: Fix bandwidth group reservation indexing
thunderbolt: stream: Unmap buffers with mapped size
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial / vt driver fixes from Greg KH:
"Here are some small serial and vt tty driver fixes for 7.2-rc7 that
resolve some reported problems. Included in here are:
- two vt core fixes
- amba-pl011 serial driver fixes
- 8250_of and 8250_dma driver fixes
- qcom-geni serial driver fix
- sc16is7xx serial driver fix
All of these have been in linux-next this week with no reported
issues"
* tag 'tty-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: amba-pl011: synchronize DMA teardown
serial: amba-pl011: cancel RS485 hrtimers after freeing IRQ
serial: amba-pl011: fix indefinite RS485 post-send delay
vt: add permission check for KDSKBMETA ioctl
vt: stabilize tty reference in kbd_keycode with tty_port_tty_get
serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx
serial: qcom-geni: fix TX DMA buffer flush
serial: 8250_dma: Clear stale RX state on shutdown
serial: sc16is7xx: enable THRI before filling TX FIFO
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some more small staging driver fixes, just for the rtl8723bs
driver, for some reported problems found with it now that people are
starting to actually test the thing with "bad" networks.
Nothing major, but good to have in the -final release. All of these
have been in linux-next for over a week with no reported problems"
* tag 'staging-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: rtl8723bs: validate monitor transmit frame lengths
staging: rtl8723bs: fix missing shared-key auth challenge length check
staging: rtl8723bs: fix OOB read in WMM_param_handler()
staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc and documentation fixes from Greg KH:
"Here are some small char/misc and nvmem and documentation fixes for
7.2-rc7 to resolve some reported issues. Included in here are:
- updates to the documentation for the kernel threat model and
security bugs to get the LLMs to actually follow what we have been
asking them to do (i.e. not claim security issues for things we do
not consider security issues.)
- nvmem driver fixes which required a tiny "layout" driver to be
added.
- fastrpc driver fixes
- mei driver fix
- counter driver fix
- binder driver fix
All of these have been in linux-next this week with no reported
problems"
* tag 'char-misc-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
docs: security-bugs: clarify some mandatory steps for AI reports
docs: coding-assistant: explain important steps when looking for bugs
docs: security-bugs: clarify what counts as a valid version
docs: threat-model: move fake devices out of "non production use"
docs: threat-model: clarify "security bug" vs "vulnerability"
counter: microchip-tcb-capture: Fix DT channel validation
mei: pull kvfree out of spinlock
rust_binder: do not query current thread for all ioctls
nvmem: layouts: Add fixed-layout driver
nvmem: apple-spmi-nvmem: wrap regmap calls to satisfy CFI
misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free
misc: fastrpc: fix channel ctx ref leak when session alloc fails
misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke
misc: fastrpc: Remove buffer from list prior to unmap operation
misc: fastrpc: Fix initial memory allocation for Audio PD memory pool
|
|
While OpenRISC currently doesn't fail to build upstream, it appears that
including <asm/smp.h> in the right headers is enough to break that -
primarily because OpenRISC's asm/smp.h header doesn't actually provide
any definition for struct cpumask. Which means the only reason we aren't
failing to build the kernel is because we've been lucky enough that
every spot including asm/smp.h already has definitions for struct
cpumask pulled in.
This became evident when trying to work on a patch series for adding
ref-counted interrupt enable/disable to the kernel, where introducing a
new interrupt_rc.h header suddenly introduced a build error on OpenRISC:
In file included from include/linux/interrupt_rc.h:17,
from include/linux/spinlock.h:60,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
from include/linux/mm.h:7,
from arch/openrisc/include/asm/pgalloc.h:20,
from arch/openrisc/include/asm/io.h:18,
from include/linux/io.h:12,
from drivers/irqchip/irq-ompic.c:61:
arch/openrisc/include/asm/smp.h:21:59: warning: 'struct cpumask'
declared inside parameter list will not be visible outside of this
definition or declaration
21 | extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
| ^~~~~~~
arch/openrisc/include/asm/smp.h:23:54: warning: 'struct cpumask'
declared inside parameter list will not be visible outside of this
definition or declaration
23 | extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
| ^~~~~~~
drivers/irqchip/irq-ompic.c: In function 'ompic_of_init':
>> drivers/irqchip/irq-ompic.c:191:28: error: passing argument 1 of
'set_smp_cross_call' from incompatible pointer type
[-Werror=incompatible-pointer-types]
191 | set_smp_cross_call(ompic_raise_softirq);
| ^~~~~~~~~~~~~~~~~~~
| |
| void (*)(const struct cpumask *, unsigned int)
arch/openrisc/include/asm/smp.h:23:32: note: expected 'void (*)(const
struct cpumask *, unsigned int)' but argument is of type 'void
(*)(const struct cpumask *, unsigned int)'
23 | extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
To fix this, let's take an example from the smp.h headers of other
architectures (x86, hexagon, arm64, probably more): just include
linux/cpumask.h at the top.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Stafford Horne <shorne@gmail.com>
Link: https://patch.msgid.link/20260804161447.84806-5-boqun@kernel.org
|
|
In order to use preempt_count() to track the interrupt disable nesting
level, __preempt_count_{add,sub}_return() are introduced, as their names
suggest, these primitives return the new value of the preempt_count()
after changing it. The following example shows the usage of it in
local_interrupt_disable():
// increase the HARDIRQ_DISABLE bit
new_count = __preempt_count_add_return(HARDIRQ_DISABLE_OFFSET);
// if it's the first-time increment, then disable the interrupt
// at hardware level.
if ((new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET) {
local_irq_save(flags);
raw_cpu_write(local_interrupt_disable_state, flags);
}
Having these primitives will avoid a read of preempt_count() after
changing preempt_count() on certain architectures.
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
Link: https://patch.msgid.link/20260804161447.84806-4-boqun@kernel.org
|
