linux-stable.git/drivers/xen, branch v6.7

xen/events: fix error code in xen_bind_pirq_msi_to_irq()

2023-11-28T11:48:27+00:00

Return -ENOMEM if xen_irq_init() fails.  currently the code returns an
uninitialized variable or zero.

Fixes: 5dd9ad32d775 ("xen/events: drop xen_allocate_irqs_dynamic()")
Signed-off-by: Dan Carpenter 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/3b9ab040-a92e-4e35-b687-3a95890a9ace@moroto.mountain
Signed-off-by: Juergen Gross

xen: privcmd: Replace zero-length array with flex-array member and use __counted_by

2023-11-17T09:47:19+00:00

Fake flexible arrays (zero-length and one-element arrays) are deprecated,
and should be replaced by flexible-array members. So, replace
zero-length array with a flexible-array member in `struct
privcmd_kernel_ioreq`.

Also annotate array `ports` with `__counted_by()` to prepare for the
coming implementation by GCC and Clang of the `__counted_by` attribute.
Flexible array members annotated with `__counted_by` can have their
accesses bounds-checked at run-time via `CONFIG_UBSAN_BOUNDS` (for array
indexing) and `CONFIG_FORTIFY_SOURCE` (for strcpy/memcpy-family functions).

This fixes multiple -Warray-bounds warnings:
drivers/xen/privcmd.c:1239:30: warning: array subscript i is outside array bounds of 'struct ioreq_port[0]' [-Warray-bounds=]
drivers/xen/privcmd.c:1240:30: warning: array subscript i is outside array bounds of 'struct ioreq_port[0]' [-Warray-bounds=]
drivers/xen/privcmd.c:1241:30: warning: array subscript i is outside array bounds of 'struct ioreq_port[0]' [-Warray-bounds=]
drivers/xen/privcmd.c:1245:33: warning: array subscript i is outside array bounds of 'struct ioreq_port[0]' [-Warray-bounds=]
drivers/xen/privcmd.c:1258:67: warning: array subscript i is outside array bounds of 'struct ioreq_port[0]' [-Warray-bounds=]

This results in no differences in binary output.

Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Kees Cook 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/ZVZlg3tPMPCRdteh@work
Signed-off-by: Juergen Gross

swiotlb-xen: provide the "max_mapping_size" method

2023-11-17T09:45:46+00:00

There's a bug that when using the XEN hypervisor with bios with large
multi-page bio vectors on NVMe, the kernel deadlocks [1].

The deadlocks are caused by inability to map a large bio vector -
dma_map_sgtable always returns an error, this gets propagated to the block
layer as BLK_STS_RESOURCE and the block layer retries the request
indefinitely.

XEN uses the swiotlb framework to map discontiguous pages into contiguous
runs that are submitted to the PCIe device. The swiotlb framework has a
limitation on the length of a mapping - this needs to be announced with
the max_mapping_size method to make sure that the hardware drivers do not
create larger mappings.

Without max_mapping_size, the NVMe block driver would create large
mappings that overrun the maximum mapping size.

Reported-by: Marek Marczykowski-Górecki 
Link: https://lore.kernel.org/stable/ZTNH0qtmint%2FzLJZ@mail-itl/ [1]
Tested-by: Marek Marczykowski-Górecki 
Suggested-by: Christoph Hellwig 
Cc: stable@vger.kernel.org
Signed-off-by: Keith Busch 
Signed-off-by: Mikulas Patocka 
Acked-by: Stefano Stabellini 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/151bef41-e817-aea9-675-a35fdac4ed@redhat.com
Signed-off-by: Juergen Gross

xen/events: remove some info_for_irq() calls in pirq handling

2023-11-15T08:51:51+00:00

Instead of the IRQ number user the struct irq_info pointer as parameter
in the internal pirq related functions. This allows to drop some calls
of info_for_irq().

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: modify internal [un]bind interfaces

2023-11-15T08:29:39+00:00

Modify the internal bind- and unbind-interfaces to take a struct
irq_info parameter. When allocating a new IRQ pass the pointer from
the allocating function further up.

This will reduce the number of info_for_irq() calls and make the code
more efficient.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: drop xen_allocate_irqs_dynamic()

2023-11-15T08:02:59+00:00

Instead of having a common function for allocating a single IRQ or a
consecutive number of IRQs, split up the functionality into the callers
of xen_allocate_irqs_dynamic().

This allows to handle any allocation error in xen_irq_init() gracefully
instead of panicing the system. Let xen_irq_init() return the irq_info
pointer or NULL in case of an allocation error.

Additionally set the IRQ into irq_info already at allocation time, as
otherwise the IRQ would be '0' (which is a valid IRQ number) until
being set.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: remove some simple helpers from events_base.c

2023-11-14T09:16:34+00:00

The helper functions type_from_irq() and cpu_from_irq() are just one
line functions used only internally.

Open code them where needed. At the same time modify and rename
get_evtchn_to_irq() to return a struct irq_info instead of the IRQ
number.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: reduce externally visible helper functions

2023-11-14T08:29:28+00:00

get_evtchn_to_irq() has only one external user while irq_from_evtchn()
provides the same functionality and is exported for a wider user base.
Modify the only external user of get_evtchn_to_irq() to use
irq_from_evtchn() instead and make get_evtchn_to_irq() static.

evtchn_from_irq() and irq_from_virq() have a single external user and
can easily be combined to a new helper irq_evtchn_from_virq() allowing
to drop irq_from_virq() and to make evtchn_from_irq() static.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: remove unused functions

2023-11-13T14:45:20+00:00

There are no users of xen_irq_from_pirq() and xen_set_irq_pending().

Remove those functions.

Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross

xen/events: fix delayed eoi list handling

2023-11-13T14:21:08+00:00

When delaying eoi handling of events, the related elements are queued
into the percpu lateeoi list. In case the list isn't empty, the
elements should be sorted by the time when eoi handling is to happen.

Unfortunately a new element will never be queued at the start of the
list, even if it has a handling time lower than all other list
elements.

Fix that by handling that case the same way as for an empty list.

Fixes: e99502f76271 ("xen/events: defer eoi in case of excessive number of events")
Reported-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Reviewed-by: Oleksandr Tyshchenko 
Signed-off-by: Juergen Gross