Re: [PATCH v2 1/4] KVM: s390: pv: Use VM_SPARSE area for guest variable storage area

[Heiko Carstens <hca@linux.ibm.com>]

On Fri, Jul 17, 2026 at 09:40:07AM +0000, sashiko-bot@kernel.org wrote:
> > +static int uv_free_range_cb(pte_t *ptep, unsigned long addr, void *data)
> > +{
> > +	pte_t pte = ptep_get(ptep);
> > +
> > +	if (!pte_present(pte))
> > +		return 0;
> > +	/*
> > +	 * Note: do not update the pte here, since there is no code which
> > +	 * accesses the memory range, besides bugs. The invalidation of ptes
> > +	 * and TLB flushing is deferred like for regular vfree() calls.
> > +	 */
> > +	__free_page(pte_page(pte));
> 
> [Severity: High]
> Does this create a window where the physical page is freed to the buddy
> allocator but still mapped in the kernel page tables?
> 
> If another CPU reallocates the freed page before free_vm_area() unmaps and
> flushes the TLB, could speculative execution or a stray kernel access to the
> old virtual address read or corrupt the new owner's data?

Intended per comment above.

> > +static int uv_alloc_range_cb(pte_t *ptep, unsigned long addr, void *data)
> > +{
> > +	struct page *page;
> > +	pte_t pte;
> > +
> > +	page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
> 
> [Severity: High]
> Can this allocation sleep while holding a spinlock?
> 
> The apply_to_page_range() function loops over the page tables and acquires
> the page table spinlock (ptl) via pte_alloc_map_lock() before invoking the
> callback.
> 
> Since GFP_KERNEL_ACCOUNT implies __GFP_DIRECT_RECLAIM, which can sleep
> and invoke the scheduler, could calling this while holding the page table
> spinlock trigger a scheduling while atomic bug or deadlock?

Odd... this is not true if apply_to_page_range() is called with init_mm.