On 11/21/2025 6:13 PM, Salvatore Bonaccorso wrote:
Hi,
On Fri, Nov 21, 2025 at 11:10:43AM +0100, Greg Kroah-Hartman wrote:
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 :(
Should maybe be updated to reflect the original upstream commit. In
fact b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of
interrupt mask") was backported to various stable series:
v5.4.301: 540aac117eaea5723cef5e4cbf3035c4ac654d92 uio_hv_generic: Let
userspace take care of interrupt mask
v5.10.246: 65d40acd911c7011745cbbd2aaac34eb5266d11e uio_hv_generic: Let
userspace take care of interrupt mask
v5.15.195: a44f61f878f32071d6378e8dd7c2d47f9490c8f7 uio_hv_generic: Let
userspace take care of interrupt mask
v6.1.156: 01ce972e6f9974a7c76943bcb7e93746917db83a uio_hv_generic: Let
userspace take care of interrupt mask
v6.6.112: 2af39ab5e6dc46b835a52e80a22d0cad430985e3 uio_hv_generic: Let
userspace take care of interrupt mask
v6.12.53: 37bd91f22794dc05436130d6983302cb90ecfe7e uio_hv_generic: Let
userspace take care of interrupt mask
v6.17.3: e29587c07537929684faa365027f4b0d87521e1b uio_hv_generic: Let userspace
take care of interrupt mask
And Peter just confirmed in
https://lore.kernel.org/stable/CAFcZKTyOcDqDJRB4sgN7Q-dabBU0eg7KKs=yBJhB=cndyy7...@mail.gmail.com/
that he is seeing the problem now as well after updating from
6.1.153-1 to 6.1.158-1 in Debian.
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?
Hi Greg,
Sorry for replying late, as I was away for personal reasons since last week.
I'll change the commit to reflect upstream commit id and resend the
patch and also include the exact older kernels info in the stable tag.
It is at least relevant for back in 6.1.y now, but I'm not sure about
the older series. I will let Naman speak up.
I guess the proper fixes tracking is a bit "tricky" because it only
affected some of the stable series, namely those which had a backport
of b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt
mask") done before the including a backport of d062463edf17
("uio_hv_generic: Set event for all channels on the device"). So this
is the reason why we seeing it first in 6.12.y stable series (but now
as well on olders), but not a problem on 6.17.y.
Hope this explanation helps, please keep in mind that I'm no expert
here by no means, just helping to report it from downstream Debian up
here.
Regards,
Salvatore
Thanks Salvatore for chiming in. I was under the impression that the
commit ids remain same across different kernel versions for the same
commit, but that was completely wrong.
Regards,
Naman
