Re: [PATCH] mshv_vtl: Check per-CPU register page before mmap

[Wei Liu <wei.liu@kernel.org>]

On Thu, Sep 24, 2026 at 12:19:32PM -0700, Hardik Garg wrote:
> 
> On 9/21/2026 5:14 PM, Michael Kelley wrote:
> > From: Hardik Garg <hargar@linux.microsoft.com>
> >> Register-page setup is optional for each CPU. If allocation or
> >> registration fails, mshv_vtl_configure_reg_page() warns and leaves that
> >> CPU's reg_page NULL, but initial context setup continues successfully.
> >> Meanwhile, successful setup on another CPU sets the global
> >> mshv_has_reg_page flag.
> >>
> >> mshv_vtl_fault() checks this global flag before selecting the requested
> >> CPU's register page. With mixed setup results across online CPUs, the
> >> check passes even for a CPU with no register page, reaching
> >> get_page(NULL) when userspace faults in that mapping.
> > I'm a bit late in reviewing this because I was travelling all last week.
> >
> > This patch seems like it is just papering over the real problem, which
> > is that a global variable like mshv_has_reg_page can't represent the
> > status of an operation that may succeed or fail on a per-cpu basis.
> > I pointed this out (as did Sashiko) in review comments back in
> > April [1].
> >
> > The only other place mshv_has_reg_page is used is in 
> > mshv_ioctl_check_extensions() where its value is returned from an
> > ioctl() system call made by user space. That's a questionable practice
> > since ioctl() usually returns 0 on success, though the man page for
> > ioctl() does admit that some ioctls use the return value as an output
> > parameter and return a non-negative value on success. But even
> > then, a single value can't accurately reflect the status of an
> > operation that may succeed or fail on a per-cpu basis. User
> > space would presumably have a similar problem to what is
> > being fixed by this patch.
> >
> > Is there any reason that the real problem couldn't be fixed
> > instead of doing this fix on top of something that is fundamentally
> > broken?
> >
> > Michael
> >
> > [1] https://lore.kernel.org/linux-hyperv/SN6PR02MB4157CF364DA2C0CC657A6DCBD450A@SN6PR02MB4157.namprd02.prod.outlook.com/
> 
> Hi Michael,
> Thanks for the feedback and for pointing me to your April review.
> After going through it, I understand that the NULL check only addresses
> the immediate fault, while the global capability still misrepresents
> per-CPU availability.
> 
> I'll work on addressing the underlying issue and send a proposed fix
> soon.

I have not seen this new fix yet. I will keep this patch for now.

Wei