All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Simon Schippers <simon.schippers@tu-dortmund.de>,
	Tim Gebauer <tim.gebauer@tu-dortmund.de>
Subject: Re: linux-next: manual merge of the vhost tree with the mm-unstable tree
Date: Thu, 4 Jun 2026 01:23:10 -0400	[thread overview]
Message-ID: <20260604012124-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <aiB6PlZxn19NobF0@sirena.org.uk>

On Wed, Jun 03, 2026 at 08:02:22PM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vhost tree got conflicts in:
> 
>   include/linux/mm.h
>   include/linux/ptr_ring.h
>   mm/memory.c
>   mm/page_alloc.c
> 
> between at least commits:
> 
>   c0ea52c18c78c ("mm/huge_memory: simplify vma_is_specal_huge()")
>   fba362c17d9d9 ("ptr_ring: move free-space check into separate helper")
>   aa812f234b6c8 ("mm: memory: flatten alloc_anon_folio() retry loop")
> 
> from the mm-unstable tree and commits:
> 
>   dd3984b3bce9d ("ptr_ring: disable KCSAN warnings")
>   fba362c17d9d9 ("ptr_ring: move free-space check into separate helper")
>   f7a2566ae0c03 ("mm: move user page zeroing into the allocator")
> 
> from the vhost tree.  I note that the vhost tree does not appear to have
> anything from Linus' tree beyond v7.0-rc2, are you sure this is
> sensible?


Not at all, somehow I pushed a wrong hash I was experimenting with (
It was never intended for next.


> I am really not convinced about my fixups below.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc include/linux/mm.h
> index 485df9c2dbddb,f600c0428aad9..0000000000000
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@@ -5088,6 -4714,25 +5100,9 @@@ long copy_folio_from_user(struct folio 
>   			   const void __user *usr_src,
>   			   bool allow_pagefault);
>   
>  -/**
>  - * vma_is_special_huge - Are transhuge page-table entries considered special?
>  - * @vma: Pointer to the struct vm_area_struct to consider
>  - *
>  - * Whether transhuge page-table entries are considered "special" following
>  - * the definition in vm_normal_page().
>  - *
>  - * Return: true if transhuge page-table entries should be considered special,
>  - * false otherwise.
>  - */
>  -static inline bool vma_is_special_huge(const struct vm_area_struct *vma)
>  -{
>  -	return vma_is_dax(vma) || (vma->vm_file &&
>  -				   (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)));
>  -}
>  -
> + #else /* !CONFIG_TRANSPARENT_HUGEPAGE && !CONFIG_HUGETLBFS */
> + #define folio_zero_user(folio, addr_hint) \
> + 	clear_user_highpages(&(folio)->page, (addr_hint), folio_nr_pages(folio))
>   #endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
>   
>   #if MAX_NUMNODES > 1
> diff --cc include/linux/ptr_ring.h
> index c95e891903f05,d2c3629bbe451..0000000000000
> --- a/include/linux/ptr_ring.h
> +++ b/include/linux/ptr_ring.h
> diff --cc mm/memory.c
> index 56be920c56d74,beb6ce312dec6..0000000000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> diff --cc mm/page_alloc.c
> index 81a9d4d1e6c0a,cb72dd6e0efb3..0000000000000
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@@ -90,8 -90,12 +90,14 @@@ typedef int __bitwise fpi_t
>   /* Free the page without taking locks. Rely on trylock only. */
>   #define FPI_TRYLOCK		((__force fpi_t)BIT(2))
>   
>  +/* free_pages_prepare() has already been called for page(s) being freed. */
>  +#define FPI_PREPARED		((__force fpi_t)BIT(3))
> + /*
> +  * The page contents are known to be zero (e.g., the host zeroed them
> +  * during balloon deflate).  Set PagePrezeroed after free so the next
> +  * allocation can skip redundant zeroing.
> +  */
>  -#define FPI_PREZEROED		((__force fpi_t)BIT(3))
> ++#define FPI_PREZEROED		((__force fpi_t)BIT(4))
>   
>   /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
>   static DEFINE_MUTEX(pcp_batch_high_lock);
> @@@ -1806,15 -1881,25 +1850,25 @@@ static inline bool should_skip_init(gfp
>   	return (flags & __GFP_SKIP_ZERO);
>   }
>   
> + 
>   inline void post_alloc_hook(struct page *page, unsigned int order,
> - 				gfp_t gfp_flags)
> + 				gfp_t gfp_flags, bool prezeroed,
> + 				unsigned long user_addr)
>   {
>  +	const bool zero_tags = gfp_flags & __GFP_ZEROTAGS;
>   	bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
>   			!should_skip_init(gfp_flags);
>  -	bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
>   	int i;
>   
> - 	set_page_private(page, 0);
> + 	__ClearPagePrezeroed(page);
> + 
> + 	/*
> + 	 * If the page is pre-zeroed, skip memory initialization.
> + 	 * We still need to handle tag zeroing separately since the host
> + 	 * does not know about memory tags.
> + 	 */
> + 	if (prezeroed && init && !zero_tags)
> + 		init = false;
>   
>   	arch_alloc_page(page, order);
>   	debug_pagealloc_map_pages(page, 1 << order);
> @@@ -3244,15 -3347,9 +3309,16 @@@ struct page *rmqueue_buddy(struct zone 
>   			}
>   		}
>   		spin_unlock_irqrestore(&zone->lock, flags);
> + 		*prezeroed = __page_test_clear_prezeroed(page);
>   	} while (check_new_pages(page, order));
>   
>  +	/*
>  +	 * If this is a high-order atomic allocation then check
>  +	 * if the pageblock should be reserved for the future
>  +	 */
>  +	if (unlikely(alloc_flags & ALLOC_HIGHATOMIC))
>  +		reserve_highatomic_pageblock(page, order, zone);
>  +
>   	__count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << order);
>   	zone_statistics(preferred_zone, zone, 1);
>   
> @@@ -3376,8 -3461,9 +3443,8 @@@ static struct page *rmqueue_pcplist(str
>   	 */
>   	pcp->free_count >>= 1;
>   	list = &pcp->lists[order_to_pindex(migratetype, order)];
> - 	page = __rmqueue_pcplist(zone, order, migratetype, alloc_flags, pcp, list);
>  -	page = __rmqueue_pcplist(zone, order, migratetype, alloc_flags,
>  -				 pcp, list, prezeroed);
>  -	pcp_spin_unlock(pcp, UP_flags);
> ++	page = __rmqueue_pcplist(zone, order, migratetype, alloc_flags, pcp, list, prezeroed);
>  +	pcp_spin_unlock(pcp);
>   	if (page) {
>   		__count_zid_vm_events(PGALLOC, page_zonenum(page), 1 << order);
>   		zone_statistics(preferred_zone, zone, 1);
> @@@ -3941,10 -4035,19 +4009,12 @@@ check_alloc_wmark
>   
>   try_this_zone:
>   		page = rmqueue(zonelist_zone(ac->preferred_zoneref), zone, order,
> - 				gfp_mask, alloc_flags, ac->migratetype);
> + 					gfp_mask, alloc_flags, ac->migratetype,
> + 					&prezeroed);
>   		if (page) {
> - 			prep_new_page(page, order, gfp_mask, alloc_flags);
> + 			prep_new_page(page, order, gfp_mask, alloc_flags,
> + 				      prezeroed, ac->user_addr);
>   
>  -			/*
>  -			 * If this is a high-order atomic allocation then check
>  -			 * if the pageblock should be reserved for the future
>  -			 */
>  -			if (unlikely(alloc_flags & ALLOC_HIGHATOMIC))
>  -				reserve_highatomic_pageblock(page, order, zone);
>  -
>   			return page;
>   		} else {
>   			if (cond_accept_memory(zone, order, alloc_flags))



      reply	other threads:[~2026-06-04  5:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 19:02 linux-next: manual merge of the vhost tree with the mm-unstable tree Mark Brown
2026-06-04  5:23 ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260604012124-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=simon.schippers@tu-dortmund.de \
    --cc=tim.gebauer@tu-dortmund.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.