Re: [PATCH v2 0/2] mshv_vtl: fix poll waitqueue handling

[Naman Jain <namjain@linux.microsoft.com>]

On 10/19/2026 2:13 PM, Daehyeon Ko wrote:
> MSHV_SET_POLL_FILE retains one embedded wait entry per CPU after vfs_poll()
> returns. Two independent bugs affect that state.
> 
> First, a provider such as signalfd may retire a non-file-owned waitqueue
> with POLLFREE. The MSHV callback leaves its entry linked and retains the
> queue pointer, allowing a later replacement to access freed provider
> memory. Patch 1 detaches on POLLFREE and introduces an RCU-safe removal
> helper.
> 
> Second, a poll callback may register more than one waitqueue. MSHV inserts
> the same embedded list node into each queue, corrupting the first list.
> Patch 2 rejects a second distinct queue and uses the common helper to
> unwind the first registration.
> 
> The roots, triggers, effects, and runtime oracles remain independent.
> Source-equivalent KASAN/LOCKDEP tests reproduced both bugs and validated
> the fixes. The local system is not a Hyper-V VTL2 environment, so the
> series has not been exercised through the real MSHV ioctl. OpenVMM does
> not exercise these paths in its current use of the interface.
> 
> An LLM assisted the source audits, fix development, and validation. Each
> patch notes that assistance in its changelog.
> 
> Changes in v2:
> - combine the two previously standalone fixes into one series;
> - rebase onto current Torvalds master;
> - introduce the removal helper in patch 1 and reuse it in patch 2;
> - replace the obsolete Assisted-by trailer with changelog prose.
> 
> Previous standalone submissions:
> - POLLFREE v1: <20261017141527.623376-1-4ncienth@gmail.com>
> - multi-waitqueue v2, now withdrawn:
>    <20261019070438.3732624-1-4ncienth@gmail.com>
> 
> Daehyeon Ko (2):
>    mshv_vtl: detach poll waiter on POLLFREE
>    mshv_vtl: reject poll files with multiple waitqueues
> 
>   drivers/hv/mshv_vtl_main.c | 51 ++++++++++++++++++++++++++++++++++----
>   1 file changed, 46 insertions(+), 5 deletions(-)
> 
> 
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222

I would suggest you to generally wait for a couple more days to collect 
other reviewers feedback as well, in case someone is reviewing your 
changes. You can then address them together in the next version.

For the series,
Reviewed-by: Naman Jain <namjain@linux.microsoft.com>

Regards,
Naman


guidance: 
https://docs.kernel.org/process/submitting-patches.html#don-t-get-discouraged-or-impatient