On Sat, Nov 15, 2025 at 02:29:37PM +0530, Naman Jain wrote:
> From: Long Li <[email protected]>
> 
> Enable the user space to manage interrupt_mask for subchannels through
> irqcontrol interface for uio device. Also remove the memory barrier
> when monitor bit is enabled as it is not necessary.
> 
> This is a backport of the upstream commit
> d062463edf17 ("uio_hv_generic: Set event for all channels on the device")
> with some modifications to resolve merge conflicts and take care of
> missing support for slow devices on older kernels.
> Original change was not a fix, but it needs to be backported to fix a
> NULL pointer crash resulting from missing interrupt mask setting.
> 
> Commit 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt 
> mask")
> removed the default setting of interrupt_mask for channels (including
> subchannels) in the uio_hv_generic driver, as it relies on the user space
> to take care of managing it. This approach works fine when user space
> can control this setting using the irqcontrol interface provided for uio
> devices. Support for setting the interrupt mask through this interface for
> subchannels came only after commit d062463edf17 ("uio_hv_generic: Set event
> for all channels on the device"). On older kernels, this change is not
> present. With uio_hv_generic no longer setting the interrupt_mask, and
> userspace not having the capability to set it, it remains unset,
> and interrupts can come for the subchannels, which can result in a crash
> in hv_uio_channel_cb. Backport the change to older kernels, where this
> change was not present, to allow userspace to set the interrupt mask
> properly for subchannels. Additionally, this patch also adds certain
> checks for primary vs subchannels in the hv_uio_channel_cb, which can
> gracefully handle these two cases and prevent the NULL pointer crashes.
> 
> Signed-off-by: Long Li <[email protected]>
> Fixes: 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt 
> mask")

This is a 6.12.y commit id, so a fix for 6.6.y does not make sense :(

> Closes: https://bugs.debian.org/1120602
> Cc: <[email protected]> # 6.6.x and older

How "old" do you want this?  Can you fix the Fixes: line up and resend
with this info?

thanks,

greg k-h

Reply via email to