The "ni_at_a2150" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT-A2150
series board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by on-board
jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-28-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "multiq3" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a Multiq-3
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-27-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "mpc624" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a MPC624
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-26-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "fl512" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an FL512
board. It currently allows any base address to be configured and uses a
16-byte register region.
I cannot find any information about this board, but assume it needs to
be aligned to a 16-byte boundary. I have no idea about the allowed
range, so allow anything in a 32-bit range and add a "FIXME" comment
(although most ancient ISA cards only support 10-bit address decoding).
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-25-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2817" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2817
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-24-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2815" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2815
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-23-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2814" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2814
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-22-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2811" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2811 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
on-board jumpers) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-21-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2801" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2801 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0x200 to 0x3fe on 2-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-20-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dmm32at" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
Diamond-MM-32-AT board. It currently allows any base address to be
configured but the hardware only supports 8 possible base addresses
(selected by 3 on-board jumpers). These are 0x100, 0x140, 0x180, 0x200,
0x280, 0x300, 0x340, and 0x380.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-19-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS800 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-18-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das6402" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS6402 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-17-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das1800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a board
compatible with the DAS1800 series. It currently allows any base
address to be configured but the hardware only supports base addresses
(configured by an on-board DIP switch) in the range 0 to 0x3f0 on
16-byte boundaries. Some boards have an additional span of up to 0x10
registers at offset 0x400 from the main 0x10 byte region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-16-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das16m1" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DAS16/M1
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0 to 0x3f0 on 16-byte boundaries. It has an
additional span of 0x8 registers at offset 0x400 from the main 0x10 byte
region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-15-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das16" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a various
DAS16 compatible boards. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16- or 32-byte
boundaries. Some of the boards have an 8255 chip at offset 0x10 and
require the board to be configured on a 32-byte boundary unless some
on-board jumpers are set to limit the board to decoding only the first
0x10 registers, disabling access to the 8255. Some other boards place
the 8255 chip (and some other registers) at offset 0x400 from the base
address, decoding 0x10 registers at the base address and 0x8 registers
at the base address plus 0x400.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the device has the 8255 chip at offset
0x10, and is being configured with the base address at an odd 16-byte
boundary, limit the size of the region to 0x10 and disable the 8255
subdevice.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-14-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das08_isa" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS08 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
(Technically, the DIP switches allow 8-byte boundaries, but I do not
think that is advisable given that the boards decode an 16-byte address
range.)
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-13-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dac02" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
DAC-02 board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-12-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "comedi_parport" driver treats a standard printer parallel port as a
COMEDI digital I/O device, driving the port's I/O registers directly.
It uses an admin-supplied configuration option (`it->options[0]`) to
configure the I/O port base address of the device. Currently, the
driver allows any I/O base address to be specified as long as the I/O
region can be reserved, and it converts the specified `int` option value
holding the base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries (for SPP printer ports, although printer ports with
EPP/ECP support actually need to be aligned on 8-byte boundaries), so
add a check for 4-byte alignment.
Convert the option value that specifies the base address from `int` to
`unsigned int` instead of `unsigned long` so it ends up the same on
32-bit and 64-bit systems.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-11-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "c6xdigio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
C6x_DIGIO DSP device connected to a PC printer parallel port (driving
the port's I/O registers directly). Currently, the driver allows any
I/O base address to be specified as long as the I/O region can be
reserved, and it converts the specified `int` option value holding the
base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries (for SPP printer ports, although printer ports with
EPP/ECP support actually need to be aligned on 8-byte boundaries), so
add a check for 4-byte alignment.
Convert the option value that specifies the base address from `int` to
`unsigned int` instead of `unsigned long` so it ends up the same on
32-bit and 64-bit systems.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-10-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "amplc_pc263" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
PC263 board. It currently allows any base address to be configured but
the hardware only supports base addresses (set by on-board DIP switches)
in the range 0 to 0x7FE on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-9-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "amplc_pc236" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
PC36AT board. It currently allows any base address to be configured but
the hardware only supports base addresses (set by on-board DIP switches)
in the range 0 to 0xFFC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-8-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "amplc_dio200" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (PC212E, PC214E, PC215E, PC218E, or PC272E). It currently allows
any base address to be configured but the hardware only supports base
addresses (set by on-board DIP switches) in the range 0 to 0xFE0 on
32-byte boundaries. (Technically, the DIP switches allow 16-byte
boundaries, but I do not think that is advisable given that the boards
decode a 32-byte address range.)
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-7-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "aio_iiro_16" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (IIRO-16). It currently allows any base address to be configured
but the hardware only supports base addresses (set by on-board jumpers)
in the range 0x100 to 0x3F8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-6-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "aio_aio12_8" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (AIO12-8, AI12-8, or AO12-4). It currently allows any base
address to be configured but the hardware only supports base addresses
(set by on-board jumpers) in the range 0x100 to 0x3C0 on 32-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-5-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "adq12b" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of the ADQ12-B
board. It currently allows any base address to be configured but the
hardware only supports the following base addresses (set by an on-board
jumper): 0x300, 0x320, 0x340, 0x360, 0x380, 0x3A0.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-4-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "8255" driver allows a COMEDI device to be constructed from one or
more 8255 chips, each at an I/O port base address specified by the
admin-supplied configuration options (`it->options[]`). Currently, the
driver allows any I/O base addresses to be specified as long as the I/O
regions can be reserved, and it converts the specified `int` option
values holding the base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries because the hardware register addresses would not be
decoded properly, so add a check for valid alignment.
Convert the option values that specify the base addresses from `int` to
`unsigned int` instead of `unsigned long` so they end up the same on
32-bit and 64-bit systems.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-3-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is an existing comedi_request_region(dev, start, len) function
used by COMEDI drivers for legacy devices to request an I/O port region
starting at a specified base address (which must be non-zero) and with a
specified length. It uses request_region(). On success, it sets
dev->iobase and dev->iolen and returns 0. There is a alternative
function __comedi_request_region(dev, start, len) which does the same
thing without setting dev->iobase and dev->iolen.
Most hardware devices have restrictions on the allowed I/O port base
address and alignment, so add new functions
comedi_check_request_region(dev, start, len, minstart, maxend, minalign)
and __comedi_check_request_region(dev, start, len, minstart, maxend,
minalign) to perform these additional checks. Turn the original
functions into static inline wrapper functions that call the new
functions.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-2-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that all the bits are properly addressed, provide a mechanism
for testing ESA mode guests in nested configurations.
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
[farman@us.ibm.com: Updated commit message]
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
The prefix page address occupies a different number
of bits for z/Architecture versus ESA mode. Adjust the
definition to cover both, and permit an ESA mode
address within the nested codepath.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
In the event that a nested guest is put in ESA mode,
ensure that some bits are scrubbed from the shadow SCB.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Linux/KVM runs in z/Architecture-only mode. Although z/Architecture
is built upon a long history of hardware refinements, any other
CPU mode is not permitted.
Allow a userspace to explicitly enable the use of ESA mode for
nested guests, otherwise usage will be rejected.
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
The hotplug testing only tries reading a trace remote buffer, loaded
before a CPU is offline. Extend this testing to cover:
* A trace remote buffer loaded after a CPU is offline.
* A trace remote buffer loaded before a CPU is online.
Because of these added test cases, move the hotplug testing into a
separate hotplug.tc file.
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260401045100.3394299-3-vdonnefort@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
When a trace_buffer is created while a CPU is offline, this CPU is
cleared from the trace_buffer CPU mask, preventing the creation of a
non-consuming iterator (ring_buffer_iter). For trace remotes, it means
the iterator fails to be allocated (-ENOMEM) even though there are
available ring buffers in the trace_buffer.
For non-consuming reads of trace remotes, skip missing ring_buffer_iter
to allow reading the available ring buffers.
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260401045100.3394299-2-vdonnefort@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
It is not necessary to update REG_RX_CPU_IDX register for each iteration
of the descriptor loop in airoha_qdma_fill_rx_queue routine.
Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
the last queue head value updated in the descriptor loop.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260331-airoha-cpu-idx-out-off-loop-v1-1-75c66b428f50@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix a simple naming issue in the documentation: the completion
routine is called bi_end_io and not bi_complete.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/20260401135854.125109-1-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Regression tests for the shared-block NULL derefs fixed in the previous
two patches:
- fw: attempt to attach an empty fw filter to a shared block and
verify the configuration is rejected with EINVAL.
- flow: create a flow filter on a shared block without a baseclass
and verify the configuration is rejected with EINVAL.
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/20260331050217.504278-3-xmei5@asu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass. Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.
Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks. This avoids the null-deref shown below:
=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
tc_new_tfilter (net/sched/cls_api.c:2432)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
[...]
=======================================================================
Fixes: 1abf272022 ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260331050217.504278-2-xmei5@asu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle. Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.
Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
Call Trace:
tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
tc_run (net/core/dev.c:4401)
__dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
Fixes: 1abf272022 ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260331050217.504278-1-xmei5@asu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When a bio is allocated from the mempool with REQ_ALLOC_CACHE set and
later completed, bio_put() places it into the per-cpu bio_alloc_cache
via bio_put_percpu_cache() instead of freeing it back to the
mempool/slab. The slab allocation remains tracked by kmemleak, but the
only reference to the bio is through the percpu cache's free_list,
which kmemleak fails to trace through percpu memory. This causes
kmemleak to report the cached bios as unreferenced objects.
Use symmetric kmemleak_free()/kmemleak_alloc() calls to properly track
bios across percpu cache transitions:
- bio_put_percpu_cache: call kmemleak_free() when a bio enters the
cache, unregistering it from kmemleak tracking.
- bio_alloc_percpu_cache: call kmemleak_alloc() when a bio is taken
from the cache for reuse, re-registering it so that genuine leaks
of reused bios remain detectable.
- __bio_alloc_cache_prune: call kmemleak_alloc() before bio_free() so
that kmem_cache_free()'s internal kmemleak_free() has a matching
allocation to pair with.
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://patch.msgid.link/20260326144058.2392319-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The following fix in sched/urgent:
e08d007f9d ("sched/debug: Fix avg_vruntime() usage")
is in conflict with this pending commit in sched/core:
4823725d9d ("sched/fair: Increase weight bits for avg_vruntime")
Both modify the same variable definition and initialization blocks,
resolve it by merging the two.
Conflicts:
kernel/sched/debug.c
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently, kvm_arch_vcpu_load() unconditionally restores guest CSRs,
HGATP, and AIA state. However, when a VCPU is loaded back on the same
physical CPU, and no other KVM VCPU has run on this CPU since it was
last put, the hardware CSRs and AIA registers are still valid.
This patch optimizes the vcpu_load path by skipping the expensive CSR
and AIA writes if all the following conditions are met:
1. It is being reloaded on the same CPU (vcpu->arch.last_exit_cpu == cpu).
2. The CSRs are not dirty (!vcpu->arch.csr_dirty).
3. No other VCPU used this CPU (vcpu == __this_cpu_read(kvm_former_vcpu)).
To ensure this fast-path doesn't break corner cases:
- Live migration and VCPU reset are naturally safe. KVM initializes
last_exit_cpu to -1, which guarantees the fast-path won't trigger.
- The 'csr_dirty' flag tracks runtime userspace interventions. If
userspace modifies guest configurations (e.g., hedeleg via
KVM_SET_GUEST_DEBUG, or CSRs including AIA via KVM_SET_ONE_REG),
the flag is set to skip the fast path.
With the 'csr_dirty' safeguard proven effective, it is safe to
include kvm_riscv_vcpu_aia_load() inside the skip logic now.
Signed-off-by: Jinyu Tang <tjytimi@163.com>
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260227121008.442241-1-tjytimi@163.com
Signed-off-by: Anup Patel <anup@brainfault.org>
After commit a9165b83c1 ("io_uring/rw: always setup io_async_rw for
read/write requests") which moved the iovec allocation into the prep
path and stores it in req->async_data where it now gets freed as part of
the request lifecycle, this comment is now outdated.
Remove it and clean up the goto as well.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20260401173511.4052303-1-joannelkoong@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Buffers are now dma-mapped earlier and we can sg_dma_len(), otherwise,
since it's walking with for_each_sgtable_dma_sg(), it might wrongfully
reject some configurations. As a bonus, it'd now be able to use larger
chunks if dma addresses are coalesced e.g by iommu.
Fixes: 8c0cab0b7bf7 ("io_uring/zcrx: always dma map in advance")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/03b219af3f6cfdd1cf64679b8bab7461e47cc123.1774780198.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Now that area->is_mapped is set earlier before niovs array is allocated,
io_zcrx_free_area -> io_zcrx_unmap_area in an error path can try to
clear dma addresses for unallocated niovs, fix it.
Fixes: 8c0cab0b7bf7 ("io_uring/zcrx: always dma map in advance")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/cbcb7749b5a001ecd4d1c303515ce9403215640c.1774780198.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In the SDSP probe path, qcom_scm_assign_mem() is used to assign the
reserved memory to the configured VMIDs, but its return value was not checked.
Fail the probe if the SCM call fails to avoid continuing with an
unexpected/incorrect memory permission configuration.
This issue was found by an in-house analysis workflow that extracts AST-based
information and runs static checks, with LLM assistance for triage, and was
confirmed by manual code review.
No hardware testing was performed.
Fixes: c3c0363bc7 ("misc: fastrpc: support complete DMA pool access to the DSP")
Cc: stable@vger.kernel.org # 6.11-rc1
Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260131065539.2124047-1-xjdeng@buaa.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fastrpc_init_create_static_process() may free cctx->remote_heap on the
err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
frees cctx->remote_heap again if it is non-NULL, which can lead to a
double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
device is subsequently removed/unbound.
Clear cctx->remote_heap after freeing it in the error path to prevent the
later cleanup from freeing it again.
This issue was found by an in-house analysis workflow that extracts AST-based
information and runs static checks, with LLM assistance for triage, and was
confirmed by manual code review.
No hardware testing was performed.
Fixes: 0871561055 ("misc: fastrpc: Add support for audiopd")
Cc: stable@vger.kernel.org # 6.2+
Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260129234140.410983-1-xjdeng@buaa.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
syzbot reported a memory leak [1], because commit 4e1da516de ("comedi:
Add reference counting for Comedi command handling") did not consider
the exceptional exit case in do_cmd_ioctl() where runflags is not set.
This caused chanlist not to be properly freed by do_become_nonbusy(),
as it only frees chanlist when runflags is correctly set.
Added a check in do_become_nonbusy() for the case where runflags is not
set, to properly free the chanlist memory.
[1]
BUG: memory leak
backtrace (crc 844a0efa):
__comedi_get_user_chanlist drivers/comedi/comedi_fops.c:1815 [inline]
do_cmd_ioctl.part.0+0x112/0x350 drivers/comedi/comedi_fops.c:1890
do_cmd_ioctl drivers/comedi/comedi_fops.c:1858 [inline]
Fixes: 4e1da516de ("comedi: Add reference counting for Comedi command handling")
Reported-by: syzbot+f238baf6ded841b5a82e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f238baf6ded841b5a82e
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@kernel.org> # 6.19
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260310111104.70959-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
