linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-02-24 23:39 Stephen Rothwell
  2023-02-25  2:04 ` Andrew Morton
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-02-24 23:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Charan Teja Kalla, Christian Brauner (Microsoft),
	Giuseppe Scrivano, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/shmem.c

between commit:

  7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs")

from Linus' tree and commit:

  9323c8b93d95 ("mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem")

from the mm tree.

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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/shmem.c
index 448f393d8ab2,31bd5e1f9faa..000000000000
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@@ -2344,9 -2347,120 +2347,121 @@@ static void shmem_set_inode_flags(struc
  #define shmem_initxattrs NULL
  #endif
  
+ static void shmem_isolate_pages_range(struct address_space *mapping, loff_t start,
+ 				loff_t end, struct list_head *list)
+ {
+ 	XA_STATE(xas, &mapping->i_pages, start);
+ 	struct folio *folio;
+ 
+ 	rcu_read_lock();
+ 	xas_for_each(&xas, folio, end) {
+ 		if (xas_retry(&xas, folio))
+ 			continue;
+ 		if (xa_is_value(folio))
+ 			continue;
+ 
+ 		if (!folio_try_get(folio))
+ 			continue;
+ 		if (folio_test_unevictable(folio) || folio_mapped(folio) ||
+ 				folio_isolate_lru(folio)) {
+ 			folio_put(folio);
+ 			continue;
+ 		}
+ 		folio_put(folio);
+ 
+ 		/*
+ 		 * Prepare the folios to be passed to reclaim_pages().
+ 		 * VM can't reclaim a folio unless young bit is
+ 		 * cleared in its flags.
+ 		 */
+ 		folio_clear_referenced(folio);
+ 		folio_test_clear_young(folio);
+ 		list_add(&folio->lru, list);
+ 		if (need_resched()) {
+ 			xas_pause(&xas);
+ 			cond_resched_rcu();
+ 		}
+ 	}
+ 	rcu_read_unlock();
+ }
+ 
+ static int shmem_fadvise_dontneed(struct address_space *mapping, loff_t start,
+ 				loff_t end)
+ {
+ 	LIST_HEAD(folio_list);
+ 
+ 	if (!total_swap_pages || mapping_unevictable(mapping))
+ 		return 0;
+ 
+ 	lru_add_drain();
+ 	shmem_isolate_pages_range(mapping, start, end, &folio_list);
+ 	reclaim_pages(&folio_list);
+ 
+ 	return 0;
+ }
+ 
+ static int shmem_fadvise_willneed(struct address_space *mapping,
+ 				 pgoff_t start, pgoff_t long end)
+ {
+ 	struct folio *folio;
+ 	pgoff_t index;
+ 
+ 	xa_for_each_range(&mapping->i_pages, index, folio, start, end) {
+ 		if (!xa_is_value(folio))
+ 			continue;
+ 		folio = shmem_read_folio(mapping, index);
+ 		if (!IS_ERR(folio))
+ 			folio_put(folio);
+ 	}
+ 
+ 	return 0;
+ }
+ 
+ static int shmem_fadvise(struct file *file, loff_t offset, loff_t len, int advice)
+ {
+ 	loff_t endbyte;
+ 	pgoff_t start_index;
+ 	pgoff_t end_index;
+ 	struct address_space *mapping;
+ 	struct inode *inode = file_inode(file);
+ 	int ret = 0;
+ 
+ 	if (S_ISFIFO(inode->i_mode))
+ 		return -ESPIPE;
+ 
+ 	mapping = file->f_mapping;
+ 	if (!mapping || len < 0 || !shmem_mapping(mapping))
+ 		return -EINVAL;
+ 
+ 	endbyte = fadvise_calc_endbyte(offset, len);
+ 
+ 	start_index = offset >> PAGE_SHIFT;
+ 	end_index   = endbyte >> PAGE_SHIFT;
+ 	switch (advice) {
+ 	case POSIX_FADV_DONTNEED:
+ 		ret = shmem_fadvise_dontneed(mapping, start_index, end_index);
+ 		break;
+ 	case POSIX_FADV_WILLNEED:
+ 		ret = shmem_fadvise_willneed(mapping, start_index, end_index);
+ 		break;
+ 	case POSIX_FADV_NORMAL:
+ 	case POSIX_FADV_RANDOM:
+ 	case POSIX_FADV_SEQUENTIAL:
+ 	case POSIX_FADV_NOREUSE:
+ 		/*
+ 		 * No bad return value, but ignore advice.
+ 		 */
+ 		break;
+ 	default:
+ 		return -EINVAL;
+ 	}
+ 
+ 	return ret;
+ }
+ 
 -static struct inode *shmem_get_inode(struct super_block *sb, struct inode *dir,
 -				     umode_t mode, dev_t dev, unsigned long flags)
 +static struct inode *shmem_get_inode(struct mnt_idmap *idmap, struct super_block *sb,
 +				     struct inode *dir, umode_t mode, dev_t dev,
 +				     unsigned long flags)
  {
  	struct inode *inode;
  	struct shmem_inode_info *info;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-02-24 23:39 linux-next: manual merge of the mm tree with Linus' tree Stephen Rothwell
@ 2023-02-25  2:04 ` Andrew Morton
  2023-02-25  7:13   ` Christian Brauner
  0 siblings, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2023-02-25  2:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Charan Teja Kalla, Christian Brauner (Microsoft),
	Giuseppe Scrivano, Linux Kernel Mailing List,
	Linux Next Mailing List

On Sat, 25 Feb 2023 10:39:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/shmem.c
> 
> between commit:
> 
>   7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs")

mm/shmem.c is under, umm, mm/.

Said patch was not made available to the linux-mm subscribers or to the
shmem.c developers.  It doesn't have a Link: tag and doesn't appear to
have been cc:linux-kernel and a google search for the title doesn't tell
me much.

> from Linus' tree and commit:
> 
>   9323c8b93d95 ("mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem")
> 
> from the mm tree.

"mm-unstable tree", thankfully.

Is OK thanks, I'll fix this up when I resync with upstream.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-02-25  2:04 ` Andrew Morton
@ 2023-02-25  7:13   ` Christian Brauner
  2023-02-25 20:52     ` Andrew Morton
  0 siblings, 1 reply; 30+ messages in thread
From: Christian Brauner @ 2023-02-25  7:13 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Charan Teja Kalla, Giuseppe Scrivano,
	Linux Kernel Mailing List, Linux Next Mailing List

On Fri, Feb 24, 2023 at 06:04:43PM -0800, Andrew Morton wrote:
> On Sat, 25 Feb 2023 10:39:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the mm tree got a conflict in:
> > 
> >   mm/shmem.c
> > 
> > between commit:
> > 
> >   7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs")
> 
> mm/shmem.c is under, umm, mm/.
> 
> Said patch was not made available to the linux-mm subscribers or to the
> shmem.c developers.  It doesn't have a Link: tag and doesn't appear to
> have been cc:linux-kernel and a google search for the title doesn't tell
> me much.

Hey Andrew,

Sorry, I picked up that patch because it deals with a vfs only feature
we maintain. It has no implications for mm and just deals with per-mount
file ownership changes (Detailed documentation under
Documentation/filesystems/idmappings.rst. It needs updates as of v6.3
but is correct otherwise.). While Hugh was Cced I didn't pay more
attention to what lists were Cced. Sorry about that. But again, it
really has no consequences for mm otherwise I'd never have taken it.

Re Link: Patches I pick up don't have Link [1] tags pointing to the
submission on lore as Linus had said in a discussion in 2022 that he
prefers to not have the lore links in the commit message at all.

[1]: https://lore.kernel.org/linux-fsdevel/20230120094346.3182328-1-gscrivan@redhat.com

Thanks!
Christian

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-02-25  7:13   ` Christian Brauner
@ 2023-02-25 20:52     ` Andrew Morton
  2023-02-27 10:18       ` Christian Brauner
  0 siblings, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2023-02-25 20:52 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Stephen Rothwell, Charan Teja Kalla, Giuseppe Scrivano,
	Linux Kernel Mailing List, Linux Next Mailing List

On Sat, 25 Feb 2023 08:13:55 +0100 Christian Brauner <brauner@kernel.org> wrote:

> Re Link: Patches I pick up don't have Link [1] tags pointing to the
> submission on lore as Linus had said in a discussion in 2022 that he
> prefers to not have the lore links in the commit message at all.

Surprised.  What was his reasoning?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-02-25 20:52     ` Andrew Morton
@ 2023-02-27 10:18       ` Christian Brauner
  2023-02-27 17:55         ` Andrew Morton
  0 siblings, 1 reply; 30+ messages in thread
From: Christian Brauner @ 2023-02-27 10:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Charan Teja Kalla, Giuseppe Scrivano,
	Linux Kernel Mailing List, Linux Next Mailing List

On Sat, Feb 25, 2023 at 12:52:27PM -0800, Andrew Morton wrote:
> On Sat, 25 Feb 2023 08:13:55 +0100 Christian Brauner <brauner@kernel.org> wrote:
> 
> > Re Link: Patches I pick up don't have Link [1] tags pointing to the
> > submission on lore as Linus had said in a discussion in 2022 that he
> > prefers to not have the lore links in the commit message at all.
> 
> Surprised.  What was his reasoning?

Sorry, it took me a while to track down the mail where he complained
about that:

https://lore.kernel.org/lkml/20220516045821-mutt-send-email-mst@kernel.org/T/

I generally think they are useful but I also don't have a strong opinion
on this matter.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-02-27 10:18       ` Christian Brauner
@ 2023-02-27 17:55         ` Andrew Morton
  0 siblings, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2023-02-27 17:55 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Stephen Rothwell, Charan Teja Kalla, Giuseppe Scrivano,
	Linux Kernel Mailing List, Linux Next Mailing List

On Mon, 27 Feb 2023 11:18:49 +0100 Christian Brauner <brauner@kernel.org> wrote:

> On Sat, Feb 25, 2023 at 12:52:27PM -0800, Andrew Morton wrote:
> > On Sat, 25 Feb 2023 08:13:55 +0100 Christian Brauner <brauner@kernel.org> wrote:
> > 
> > > Re Link: Patches I pick up don't have Link [1] tags pointing to the
> > > submission on lore as Linus had said in a discussion in 2022 that he
> > > prefers to not have the lore links in the commit message at all.
> > 
> > Surprised.  What was his reasoning?
> 
> Sorry, it took me a while to track down the mail where he complained
> about that:
> 
> https://lore.kernel.org/lkml/20220516045821-mutt-send-email-mst@kernel.org/T/
> 
> I generally think they are useful but I also don't have a strong opinion
> on this matter.

Well, I cheerfully disagree.  A Link: to the original patch submission
also guides the reader to any followup discussion.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-28  0:00   ` Stephen Rothwell
@ 2023-07-28  3:13     ` Matthew Wilcox
  0 siblings, 0 replies; 30+ messages in thread
From: Matthew Wilcox @ 2023-07-28  3:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Suren Baghdasaryan

On Fri, Jul 28, 2023 at 10:00:47AM +1000, Stephen Rothwell wrote:
> I have gone with below.  Again, please check.

LGTM

> diff --cc mm/memory.c
> index ca632b58f792,271982fab2b8..000000000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@@ -5392,32 -5597,18 +5597,21 @@@ retry
>   	if (!vma)
>   		goto inval;
>   
> - 	/* Only anonymous and tcp vmas are supported for now */
> - 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
>  -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
>  -	if (vma_is_anonymous(vma) && !vma->anon_vma)
> --		goto inval;
> --
>   	if (!vma_start_read(vma))
>   		goto inval;
>   
>  +	/*
>  +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
>  +	 * This check must happen after vma_start_read(); otherwise, a
>  +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
>  +	 * from its anon_vma.
>  +	 */
> - 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> - 		goto inval_end_read;
> - 
> - 	/*
> - 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> - 	 * it for now and fall back to page fault handling under mmap_lock.
> - 	 */
> - 	if (userfaultfd_armed(vma))
> ++	if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
>  +		goto inval_end_read;
>  +
>   	/* Check since vm_start/vm_end might change before we lock the VMA */
>  -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
>  -		vma_end_read(vma);
>  -		goto inval;
>  -	}
>  +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
>  +		goto inval_end_read;
>   
>   	/* Check if the VMA got isolated after we found it */
>   	if (vma->detached) {

If Andrew wants to rebase on Linus' tree, I'll be happy to respin
on top of that.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-28  0:29       ` Stephen Rothwell
@ 2023-07-28  0:30         ` Suren Baghdasaryan
  0 siblings, 0 replies; 30+ messages in thread
From: Suren Baghdasaryan @ 2023-07-28  0:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Matthew Wilcox, Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Jul 27, 2023 at 5:29 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Suren,
>
> On Thu, 27 Jul 2023 17:23:45 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
> >
>  Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma
> > under vma lock") should be adding a "inval_end_read" label. At least I
> > see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/
> > and will check Linus' tree in a min. I don't see that label in your
> > patch...
>
> It's there in the file, but did not conflict with anything.  What I
> published is not a "patch" as such, but a diff showing the conflict
> resolution.

Ah, sorry for the noise then.

>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-28  0:23     ` Suren Baghdasaryan
@ 2023-07-28  0:29       ` Stephen Rothwell
  2023-07-28  0:30         ` Suren Baghdasaryan
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-28  0:29 UTC (permalink / raw)
  To: Suren Baghdasaryan
  Cc: Matthew Wilcox, Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Hi Suren,

On Thu, 27 Jul 2023 17:23:45 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
>
 Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma
> under vma lock") should be adding a "inval_end_read" label. At least I
> see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/
> and will check Linus' tree in a min. I don't see that label in your
> patch...

It's there in the file, but did not conflict with anything.  What I
published is not a "patch" as such, but a diff showing the conflict
resolution.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-28  0:21   ` Stephen Rothwell
@ 2023-07-28  0:23     ` Suren Baghdasaryan
  2023-07-28  0:29       ` Stephen Rothwell
  0 siblings, 1 reply; 30+ messages in thread
From: Suren Baghdasaryan @ 2023-07-28  0:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Matthew Wilcox, Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Jul 27, 2023 at 5:21 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Matthew,
>
> On Fri, 28 Jul 2023 00:49:50 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Jul 28, 2023 at 09:18:49AM +1000, Stephen Rothwell wrote:
> > > diff --cc mm/memory.c
> > > index ca632b58f792,271982fab2b8..000000000000
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> > >     if (!vma)
> > >             goto inval;
> > >
> > > -   /* Only anonymous and tcp vmas are supported for now */
> > > -   if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> > >  -  /* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> > >  -  if (vma_is_anonymous(vma) && !vma->anon_vma)
> > > --          goto inval;
> > > --
> > >     if (!vma_start_read(vma))
> > >             goto inval;
> > >
> > >  +  /*
> > >  +   * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> > >  +   * This check must happen after vma_start_read(); otherwise, a
> > >  +   * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> > >  +   * from its anon_vma.
> > >  +   */
> > > -   if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > > -           goto inval_end_read;
> > > -
> > > -   /*
> > > -    * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > > -    * it for now and fall back to page fault handling under mmap_lock.
> > > -    */
> > > -   if (userfaultfd_armed(vma))
> > > ++  if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
> > >  +          goto inval_end_read;
> > >  +
> >
> > No, this isn't right.  It should be:
> >
> >       if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
> >               goto inval_end_read;
>
> Yeah, see my second attempt.
>
> > I'm not sure about the userfaultfd_armed() clause.  My patch wasn't
> > intended to affect that.
>
> That was removed by commit
>
>   69f6bbd1317f ("mm: handle userfaults under VMA lock")
>
> in the mm branch.


Hmm. 657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma
under vma lock") should be adding a "inval_end_read" label. At least I
see it in https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com/
and will check Linus' tree in a min. I don't see that label in your
patch...
I also misspoke in my previous message. The patches in mm tree remove
some code from that function, so it's easier to apply them first and
then the one from Linus' tree.

>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:49 ` Matthew Wilcox
@ 2023-07-28  0:21   ` Stephen Rothwell
  2023-07-28  0:23     ` Suren Baghdasaryan
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-28  0:21 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

Hi Matthew,

On Fri, 28 Jul 2023 00:49:50 +0100 Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Jul 28, 2023 at 09:18:49AM +1000, Stephen Rothwell wrote:
> > diff --cc mm/memory.c
> > index ca632b58f792,271982fab2b8..000000000000
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> >   	if (!vma)
> >   		goto inval;
> >   
> > - 	/* Only anonymous and tcp vmas are supported for now */
> > - 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> >  -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> >  -	if (vma_is_anonymous(vma) && !vma->anon_vma)
> > --		goto inval;
> > --
> >   	if (!vma_start_read(vma))
> >   		goto inval;
> >   
> >  +	/*
> >  +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> >  +	 * This check must happen after vma_start_read(); otherwise, a
> >  +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> >  +	 * from its anon_vma.
> >  +	 */
> > - 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > - 		goto inval_end_read;
> > - 
> > - 	/*
> > - 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > - 	 * it for now and fall back to page fault handling under mmap_lock.
> > - 	 */
> > - 	if (userfaultfd_armed(vma))
> > ++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
> >  +		goto inval_end_read;
> >  +  
> 
> No, this isn't right.  It should be:
> 
> 	if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
> 		goto inval_end_read;

Yeah, see my second attempt.

> I'm not sure about the userfaultfd_armed() clause.  My patch wasn't
> intended to affect that.

That was removed by commit

  69f6bbd1317f ("mm: handle userfaults under VMA lock")

in the mm branch.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:50     ` Matthew Wilcox
@ 2023-07-28  0:08       ` Suren Baghdasaryan
  0 siblings, 0 replies; 30+ messages in thread
From: Suren Baghdasaryan @ 2023-07-28  0:08 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Stephen Rothwell, Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Jul 27, 2023 at 4:50 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Jul 27, 2023 at 04:40:20PM -0700, Suren Baghdasaryan wrote:
> > On Thu, Jul 27, 2023 at 4:29 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > On Fri, 28 Jul 2023 09:18:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Today's linux-next merge of the mm tree got a conflict in:
> > > >
> > > >   mm/memory.c
> > > >
> > > > between commit:
> > > >
> > > >   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")
> > > >
> > > > from Linus' tree and commits:
> > > >
> > > >   69f6bbd1317f ("mm: handle userfaults under VMA lock")
> > > >   a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")
> > > >
> > > > from the mm tree.
> > > >
> > > > I fixed it up (I think, please check - 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.
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> > > >
> > > > diff --cc mm/memory.c
> > > > index ca632b58f792,271982fab2b8..000000000000
> > > > --- a/mm/memory.c
> > > > +++ b/mm/memory.c
> > > > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> > > >       if (!vma)
> > > >               goto inval;
> > > >
> > > > -     /* Only anonymous and tcp vmas are supported for now */
> > > > -     if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> > > >  -    /* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> > > >  -    if (vma_is_anonymous(vma) && !vma->anon_vma)
> > > > --            goto inval;
> > > > --
> > > >       if (!vma_start_read(vma))
> > > >               goto inval;
> > > >
> > > >  +    /*
> > > >  +     * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> > > >  +     * This check must happen after vma_start_read(); otherwise, a
> > > >  +     * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> > > >  +     * from its anon_vma.
> > > >  +     */
> > > > -     if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > > > -             goto inval_end_read;
> > > > -
> > > > -     /*
> > > > -      * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > > > -      * it for now and fall back to page fault handling under mmap_lock.
> > > > -      */
> > > > -     if (userfaultfd_armed(vma))
> > > > ++    if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
> >
> > Is the above extra '+' what compiler complains about?
> > Patches from Linus' tree remove some code from that function, so
> > applying them first should simplify the merge.
>
> I see you're unfamiliar with the output of git diff --cc ...

guilty as charged.

>

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:29 ` Stephen Rothwell
  2023-07-27 23:40   ` Suren Baghdasaryan
@ 2023-07-28  0:00   ` Stephen Rothwell
  2023-07-28  3:13     ` Matthew Wilcox
  1 sibling, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-28  0:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jann Horn, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle),
	Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

Hi all,

On Fri, 28 Jul 2023 09:29:15 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 28 Jul 2023 09:18:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the mm tree got a conflict in:
> > 
> >   mm/memory.c
> > 
> > between commit:
> > 
> >   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")
> > 
> > from Linus' tree and commits:
> > 
> >   69f6bbd1317f ("mm: handle userfaults under VMA lock")
> >   a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")
> > 
> > from the mm tree.
> > 
> > I fixed it up (I think, please check - 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.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc mm/memory.c
> > index ca632b58f792,271982fab2b8..000000000000
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> >   	if (!vma)
> >   		goto inval;
> >   
> > - 	/* Only anonymous and tcp vmas are supported for now */
> > - 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> >  -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> >  -	if (vma_is_anonymous(vma) && !vma->anon_vma)
> > --		goto inval;
> > --
> >   	if (!vma_start_read(vma))
> >   		goto inval;
> >   
> >  +	/*
> >  +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> >  +	 * This check must happen after vma_start_read(); otherwise, a
> >  +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> >  +	 * from its anon_vma.
> >  +	 */
> > - 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > - 		goto inval_end_read;
> > - 
> > - 	/*
> > - 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > - 	 * it for now and fall back to page fault handling under mmap_lock.
> > - 	 */
> > - 	if (userfaultfd_armed(vma))
> > ++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
> >  +		goto inval_end_read;
> >  +
> >   	/* Check since vm_start/vm_end might change before we lock the VMA */
> >  -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
> >  -		vma_end_read(vma);
> >  -		goto inval;
> >  -	}
> >  +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
> >  +		goto inval_end_read;
> >   
> >   	/* Check if the VMA got isolated after we found it */
> >   	if (vma->detached) {  
> 
> Sorry, doesn't even build ... let me try that again.

I have gone with below.  Again, please check.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/memory.c
index ca632b58f792,271982fab2b8..000000000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -5392,32 -5597,18 +5597,21 @@@ retry
  	if (!vma)
  		goto inval;
  
- 	/* Only anonymous and tcp vmas are supported for now */
- 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
 -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
 -	if (vma_is_anonymous(vma) && !vma->anon_vma)
--		goto inval;
--
  	if (!vma_start_read(vma))
  		goto inval;
  
 +	/*
 +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
 +	 * This check must happen after vma_start_read(); otherwise, a
 +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
 +	 * from its anon_vma.
 +	 */
- 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
- 		goto inval_end_read;
- 
- 	/*
- 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
- 	 * it for now and fall back to page fault handling under mmap_lock.
- 	 */
- 	if (userfaultfd_armed(vma))
++	if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
 +		goto inval_end_read;
 +
  	/* Check since vm_start/vm_end might change before we lock the VMA */
 -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
 -		vma_end_read(vma);
 -		goto inval;
 -	}
 +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
 +		goto inval_end_read;
  
  	/* Check if the VMA got isolated after we found it */
  	if (vma->detached) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:40   ` Suren Baghdasaryan
@ 2023-07-27 23:50     ` Matthew Wilcox
  2023-07-28  0:08       ` Suren Baghdasaryan
  0 siblings, 1 reply; 30+ messages in thread
From: Matthew Wilcox @ 2023-07-27 23:50 UTC (permalink / raw)
  To: Suren Baghdasaryan
  Cc: Stephen Rothwell, Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Jul 27, 2023 at 04:40:20PM -0700, Suren Baghdasaryan wrote:
> On Thu, Jul 27, 2023 at 4:29 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > On Fri, 28 Jul 2023 09:18:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the mm tree got a conflict in:
> > >
> > >   mm/memory.c
> > >
> > > between commit:
> > >
> > >   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")
> > >
> > > from Linus' tree and commits:
> > >
> > >   69f6bbd1317f ("mm: handle userfaults under VMA lock")
> > >   a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")
> > >
> > > from the mm tree.
> > >
> > > I fixed it up (I think, please check - 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.
> > >
> > > --
> > > Cheers,
> > > Stephen Rothwell
> > >
> > > diff --cc mm/memory.c
> > > index ca632b58f792,271982fab2b8..000000000000
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> > >       if (!vma)
> > >               goto inval;
> > >
> > > -     /* Only anonymous and tcp vmas are supported for now */
> > > -     if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> > >  -    /* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> > >  -    if (vma_is_anonymous(vma) && !vma->anon_vma)
> > > --            goto inval;
> > > --
> > >       if (!vma_start_read(vma))
> > >               goto inval;
> > >
> > >  +    /*
> > >  +     * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> > >  +     * This check must happen after vma_start_read(); otherwise, a
> > >  +     * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> > >  +     * from its anon_vma.
> > >  +     */
> > > -     if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > > -             goto inval_end_read;
> > > -
> > > -     /*
> > > -      * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > > -      * it for now and fall back to page fault handling under mmap_lock.
> > > -      */
> > > -     if (userfaultfd_armed(vma))
> > > ++    if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
> 
> Is the above extra '+' what compiler complains about?
> Patches from Linus' tree remove some code from that function, so
> applying them first should simplify the merge.

I see you're unfamiliar with the output of git diff --cc ...


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:18 Stephen Rothwell
  2023-07-27 23:29 ` Stephen Rothwell
@ 2023-07-27 23:49 ` Matthew Wilcox
  2023-07-28  0:21   ` Stephen Rothwell
  1 sibling, 1 reply; 30+ messages in thread
From: Matthew Wilcox @ 2023-07-27 23:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Suren Baghdasaryan

On Fri, Jul 28, 2023 at 09:18:49AM +1000, Stephen Rothwell wrote:
> diff --cc mm/memory.c
> index ca632b58f792,271982fab2b8..000000000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@@ -5392,32 -5597,18 +5597,21 @@@ retry
>   	if (!vma)
>   		goto inval;
>   
> - 	/* Only anonymous and tcp vmas are supported for now */
> - 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
>  -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
>  -	if (vma_is_anonymous(vma) && !vma->anon_vma)
> --		goto inval;
> --
>   	if (!vma_start_read(vma))
>   		goto inval;
>   
>  +	/*
>  +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
>  +	 * This check must happen after vma_start_read(); otherwise, a
>  +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
>  +	 * from its anon_vma.
>  +	 */
> - 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> - 		goto inval_end_read;
> - 
> - 	/*
> - 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> - 	 * it for now and fall back to page fault handling under mmap_lock.
> - 	 */
> - 	if (userfaultfd_armed(vma))
> ++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
>  +		goto inval_end_read;
>  +

No, this isn't right.  It should be:

	if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
		goto inval_end_read;

I'm not sure about the userfaultfd_armed() clause.  My patch wasn't
intended to affect that.

>   	/* Check since vm_start/vm_end might change before we lock the VMA */
>  -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
>  -		vma_end_read(vma);
>  -		goto inval;
>  -	}
>  +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
>  +		goto inval_end_read;
>   
>   	/* Check if the VMA got isolated after we found it */
>   	if (vma->detached) {



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:29 ` Stephen Rothwell
@ 2023-07-27 23:40   ` Suren Baghdasaryan
  2023-07-27 23:50     ` Matthew Wilcox
  2023-07-28  0:00   ` Stephen Rothwell
  1 sibling, 1 reply; 30+ messages in thread
From: Suren Baghdasaryan @ 2023-07-27 23:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jann Horn, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Matthew Wilcox (Oracle)

On Thu, Jul 27, 2023 at 4:29 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Fri, 28 Jul 2023 09:18:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the mm tree got a conflict in:
> >
> >   mm/memory.c
> >
> > between commit:
> >
> >   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")
> >
> > from Linus' tree and commits:
> >
> >   69f6bbd1317f ("mm: handle userfaults under VMA lock")
> >   a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")
> >
> > from the mm tree.
> >
> > I fixed it up (I think, please check - 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.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc mm/memory.c
> > index ca632b58f792,271982fab2b8..000000000000
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@@ -5392,32 -5597,18 +5597,21 @@@ retry
> >       if (!vma)
> >               goto inval;
> >
> > -     /* Only anonymous and tcp vmas are supported for now */
> > -     if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
> >  -    /* find_mergeable_anon_vma uses adjacent vmas which are not locked */
> >  -    if (vma_is_anonymous(vma) && !vma->anon_vma)
> > --            goto inval;
> > --
> >       if (!vma_start_read(vma))
> >               goto inval;
> >
> >  +    /*
> >  +     * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> >  +     * This check must happen after vma_start_read(); otherwise, a
> >  +     * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> >  +     * from its anon_vma.
> >  +     */
> > -     if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > -             goto inval_end_read;
> > -
> > -     /*
> > -      * Due to the possibility of userfault handler dropping mmap_lock, avoid
> > -      * it for now and fall back to page fault handling under mmap_lock.
> > -      */
> > -     if (userfaultfd_armed(vma))
> > ++    if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))

Is the above extra '+' what compiler complains about?
Patches from Linus' tree remove some code from that function, so
applying them first should simplify the merge.

> >   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")

> >  +            goto inval_end_read;
> >  +
> >       /* Check since vm_start/vm_end might change before we lock the VMA */
> >  -    if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
> >  -            vma_end_read(vma);
> >  -            goto inval;
> >  -    }
> >  +    if (unlikely(address < vma->vm_start || address >= vma->vm_end))
> >  +            goto inval_end_read;
> >
> >       /* Check if the VMA got isolated after we found it */
> >       if (vma->detached) {
>
> Sorry, doesn't even build ... let me try that again.
>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-27 23:18 Stephen Rothwell
@ 2023-07-27 23:29 ` Stephen Rothwell
  2023-07-27 23:40   ` Suren Baghdasaryan
  2023-07-28  0:00   ` Stephen Rothwell
  2023-07-27 23:49 ` Matthew Wilcox
  1 sibling, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-27 23:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jann Horn, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle),
	Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

Hi all,

On Fri, 28 Jul 2023 09:18:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/memory.c
> 
> between commit:
> 
>   657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")
> 
> from Linus' tree and commits:
> 
>   69f6bbd1317f ("mm: handle userfaults under VMA lock")
>   a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")
> 
> from the mm tree.
> 
> I fixed it up (I think, please check - 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/memory.c
> index ca632b58f792,271982fab2b8..000000000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@@ -5392,32 -5597,18 +5597,21 @@@ retry
>   	if (!vma)
>   		goto inval;
>   
> - 	/* Only anonymous and tcp vmas are supported for now */
> - 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
>  -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
>  -	if (vma_is_anonymous(vma) && !vma->anon_vma)
> --		goto inval;
> --
>   	if (!vma_start_read(vma))
>   		goto inval;
>   
>  +	/*
>  +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
>  +	 * This check must happen after vma_start_read(); otherwise, a
>  +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
>  +	 * from its anon_vma.
>  +	 */
> - 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> - 		goto inval_end_read;
> - 
> - 	/*
> - 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> - 	 * it for now and fall back to page fault handling under mmap_lock.
> - 	 */
> - 	if (userfaultfd_armed(vma))
> ++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
>  +		goto inval_end_read;
>  +
>   	/* Check since vm_start/vm_end might change before we lock the VMA */
>  -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
>  -		vma_end_read(vma);
>  -		goto inval;
>  -	}
>  +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
>  +		goto inval_end_read;
>   
>   	/* Check if the VMA got isolated after we found it */
>   	if (vma->detached) {

Sorry, doesn't even build ... let me try that again.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-07-27 23:18 Stephen Rothwell
  2023-07-27 23:29 ` Stephen Rothwell
  2023-07-27 23:49 ` Matthew Wilcox
  0 siblings, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-27 23:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jann Horn, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle),
	Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/memory.c

between commit:

  657b5146955e ("mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock")

from Linus' tree and commits:

  69f6bbd1317f ("mm: handle userfaults under VMA lock")
  a3bdf38e85aa ("mm: allow per-VMA locks on file-backed VMAs")

from the mm tree.

I fixed it up (I think, please check - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/memory.c
index ca632b58f792,271982fab2b8..000000000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -5392,32 -5597,18 +5597,21 @@@ retry
  	if (!vma)
  		goto inval;
  
- 	/* Only anonymous and tcp vmas are supported for now */
- 	if (!vma_is_anonymous(vma) && !vma_is_tcp(vma))
 -	/* find_mergeable_anon_vma uses adjacent vmas which are not locked */
 -	if (vma_is_anonymous(vma) && !vma->anon_vma)
--		goto inval;
--
  	if (!vma_start_read(vma))
  		goto inval;
  
 +	/*
 +	 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
 +	 * This check must happen after vma_start_read(); otherwise, a
 +	 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
 +	 * from its anon_vma.
 +	 */
- 	if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
- 		goto inval_end_read;
- 
- 	/*
- 	 * Due to the possibility of userfault handler dropping mmap_lock, avoid
- 	 * it for now and fall back to page fault handling under mmap_lock.
- 	 */
- 	if (userfaultfd_armed(vma))
++	if (unlikely(vma_is_anonymous(vma) && !vma_is_tcp(vma)))
 +		goto inval_end_read;
 +
  	/* Check since vm_start/vm_end might change before we lock the VMA */
 -	if (unlikely(address < vma->vm_start || address >= vma->vm_end)) {
 -		vma_end_read(vma);
 -		goto inval;
 -	}
 +	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
 +		goto inval_end_read;
  
  	/* Check if the VMA got isolated after we found it */
  	if (vma->detached) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-07-06 22:54 Stephen Rothwell
@ 2023-07-07  4:52 ` Baoquan He
  0 siblings, 0 replies; 30+ messages in thread
From: Baoquan He @ 2023-07-07  4:52 UTC (permalink / raw)
  To: Stephen Rothwell, agordeev
  Cc: Andrew Morton, Alexander Gordeev, Heiko Carstens,
	Linux Kernel Mailing List, Linux Next Mailing List

On 07/07/23 at 08:54am, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   arch/s390/kernel/perf_cpum_sf.c
> 
> between commits:
> 
>   51f513fd9659 ("s390/mm: do not include <asm-generic/io.h> directly")
>   b378a9826143 ("s390: include linux/io.h instead of asm/io.h")

Thanks, Stephen.

Hi Alexander,

Since commit b378a9826143 acted to fix all places of <asm-generic/io.h>
direct including, my patch of commit 51f513fd9659 better be dropped?

> 
> from Linus' tree and commit:
> 
>   c594d5c4b630 ("s390: mm: convert to GENERIC_IOREMAP")

I forgot dropping the hunk in arch/s390/kernel/perf_cpum_sf.c and that
cause the conflict. Sorry about the inconvenience.

Thanks
Baoquan

> 
> from the mm tree.
> 
> I fixed it up (I just used the former) 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.
> 
> -- 
> Cheers,
> Stephen Rothwell



^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-07-06 22:54 Stephen Rothwell
  2023-07-07  4:52 ` Baoquan He
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2023-07-06 22:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alexander Gordeev, Baoquan He, Heiko Carstens,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  arch/s390/kernel/perf_cpum_sf.c

between commits:

  51f513fd9659 ("s390/mm: do not include <asm-generic/io.h> directly")
  b378a9826143 ("s390: include linux/io.h instead of asm/io.h")

from Linus' tree and commit:

  c594d5c4b630 ("s390: mm: convert to GENERIC_IOREMAP")

from the mm tree.

I fixed it up (I just used the former) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-06-20  9:43     ` Will Deacon
@ 2023-06-20 15:00       ` Jain, Ayush
  0 siblings, 0 replies; 30+ messages in thread
From: Jain, Ayush @ 2023-06-20 15:00 UTC (permalink / raw)
  To: Will Deacon, Andrew Morton
  Cc: Stephen Rothwell, Liam R. Howlett, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	catalin.marinas

Hello Will,
On 6/20/2023 3:13 PM, Will Deacon wrote:
> On Mon, Jun 19, 2023 at 02:39:44PM -0700, Andrew Morton wrote:
>> On Mon, 19 Jun 2023 21:43:11 +0100 Will Deacon <will@kernel.org> wrote:
>>
>>>>    	/*
>>>>    	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
>>>>    	 * VM_GROWSUP VMA. Such VMAs can change their size under
>>>
>>> This resolution seems to be causing horrible problems on arm64 with 16k
>>> pages. I see things like the crash below, but the two branches being merged
>>> are fine on their own.
>>
>> I've dropped the mm.git side of this conflict so next -next should
>> be better.
> 
> Thanks, Andrew. next-20230620 is still broken, so I came up with the diff
> below in the meantime which seems to resolve the crashes. I don't pretend
> to understand the VMA iterator stuff well enough though, so I may have
> missed something else.
> 
> Will
> 
> --->8
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 9a93b054148a..4c82e9b36fb3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2396,6 +2396,7 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
>                          if (error)
>                                  goto end_split_failed;
>                  }
> +               mas_set(&mas_detach, count);
>                  vma_start_write(next);
>                  if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
>                          goto munmap_gather_failed;


Thanks, Will. I have been able to reproduce similar kernel panics on AMD x86 platform
on next-20230619 and next-20230620.
By applying your patch kernel looks to being able to boot now.

Tested-by: Ayush Jain <Ayush.jain3@amd.com>

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-06-19 21:39   ` Andrew Morton
@ 2023-06-20  9:43     ` Will Deacon
  2023-06-20 15:00       ` Jain, Ayush
  0 siblings, 1 reply; 30+ messages in thread
From: Will Deacon @ 2023-06-20  9:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Liam R. Howlett, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	catalin.marinas

On Mon, Jun 19, 2023 at 02:39:44PM -0700, Andrew Morton wrote:
> On Mon, 19 Jun 2023 21:43:11 +0100 Will Deacon <will@kernel.org> wrote:
> 
> > >   	/*
> > >   	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
> > >   	 * VM_GROWSUP VMA. Such VMAs can change their size under
> > 
> > This resolution seems to be causing horrible problems on arm64 with 16k
> > pages. I see things like the crash below, but the two branches being merged
> > are fine on their own.
> 
> I've dropped the mm.git side of this conflict so next -next should
> be better.

Thanks, Andrew. next-20230620 is still broken, so I came up with the diff
below in the meantime which seems to resolve the crashes. I don't pretend
to understand the VMA iterator stuff well enough though, so I may have
missed something else.

Will

--->8

diff --git a/mm/mmap.c b/mm/mmap.c
index 9a93b054148a..4c82e9b36fb3 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2396,6 +2396,7 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
                        if (error)
                                goto end_split_failed;
                }
+               mas_set(&mas_detach, count);
                vma_start_write(next);
                if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
                        goto munmap_gather_failed;

^ permalink raw reply related	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-06-19 20:43 ` Will Deacon
@ 2023-06-19 21:39   ` Andrew Morton
  2023-06-20  9:43     ` Will Deacon
  0 siblings, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2023-06-19 21:39 UTC (permalink / raw)
  To: Will Deacon
  Cc: Stephen Rothwell, Liam R. Howlett, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	catalin.marinas

On Mon, 19 Jun 2023 21:43:11 +0100 Will Deacon <will@kernel.org> wrote:

> >   	/*
> >   	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
> >   	 * VM_GROWSUP VMA. Such VMAs can change their size under
> 
> This resolution seems to be causing horrible problems on arm64 with 16k
> pages. I see things like the crash below, but the two branches being merged
> are fine on their own.

I've dropped the mm.git side of this conflict so next -next should
be better.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-06-18 23:23 Stephen Rothwell
  2023-06-19 20:25 ` Andrew Morton
@ 2023-06-19 20:43 ` Will Deacon
  2023-06-19 21:39   ` Andrew Morton
  1 sibling, 1 reply; 30+ messages in thread
From: Will Deacon @ 2023-06-19 20:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Liam R. Howlett, Linus Torvalds,
	Linux Kernel Mailing List, Linux Next Mailing List,
	catalin.marinas

Hi Stephen,

On Mon, Jun 19, 2023 at 09:23:55AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/mmap.c
> 
> between commit:
> 
>   606c812eb1d5 ("mm/mmap: Fix error path in do_vmi_align_munmap()")
> 
> from the origin tree and commits:
> 
>   66106c364147 ("mm: change do_vmi_align_munmap() side tree index")
>   47b1d8de18f5 ("mm/mmap: change vma iteration order in do_vmi_align_munmap()")
> 
> from the mm tree.
> 
> I fixed it up (I think - 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/mmap.c
> index 98cda6f72605,474a0d856622..000000000000
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@@ -2398,15 -2409,27 +2396,29 @@@ do_vmi_align_munmap(struct vma_iterato
>   			if (error)
>   				goto end_split_failed;
>   		}
>  -		mas_set(&mas_detach, count);
>  -		error = munmap_sidetree(next, &mas_detach);
>  -		if (error)
>  -			goto munmap_sidetree_failed;
>  +		vma_start_write(next);
> - 		mas_set_range(&mas_detach, next->vm_start, next->vm_end - 1);
>  +		if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
>  +			goto munmap_gather_failed;
>  +		vma_mark_detached(next, true);
>  +		if (next->vm_flags & VM_LOCKED)
>  +			locked_vm += vma_pages(next);
>   
>   		count++;
> + 		if (unlikely(uf)) {
> + 			/*
> + 			 * If userfaultfd_unmap_prep returns an error the vmas
> + 			 * will remain split, but userland will get a
> + 			 * highly unexpected error anyway. This is no
> + 			 * different than the case where the first of the two
> + 			 * __split_vma fails, but we don't undo the first
> + 			 * split, despite we could. This is unlikely enough
> + 			 * failure that it's not worth optimizing it for.
> + 			 */
> + 			error = userfaultfd_unmap_prep(next, start, end, uf);
> + 
> + 			if (error)
> + 				goto userfaultfd_error;
> + 		}
>   #ifdef CONFIG_DEBUG_VM_MAPLE_TREE
>   		BUG_ON(next->vm_start < start);
>   		BUG_ON(next->vm_start > end);
> @@@ -2454,14 -2455,18 +2444,20 @@@
>   		BUG_ON(count != test_count);
>   	}
>   #endif
> - 	/* Point of no return */
>  +	error = -ENOMEM;
> - 	vma_iter_set(vmi, start);
> + 	while (vma_iter_addr(vmi) > start)
> + 		vma_iter_prev_range(vmi);
> + 
>   	if (vma_iter_clear_gfp(vmi, start, end, GFP_KERNEL))
>  -		return -ENOMEM;
>  +		goto clear_tree_failed;
>   
>  +	mm->locked_vm -= locked_vm;
>   	mm->map_count -= count;
> + 	prev = vma_iter_prev_range(vmi);
> + 	next = vma_next(vmi);
> + 	if (next)
> + 		vma_iter_prev_range(vmi);
> + 
>   	/*
>   	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
>   	 * VM_GROWSUP VMA. Such VMAs can change their size under

This resolution seems to be causing horrible problems on arm64 with 16k
pages. I see things like the crash below, but the two branches being merged
are fine on their own.

Will

--->8

[ 1353.914809] BUG: Bad rss-counter state mm:fffffff001065580 type:MM_ANONPAGES val:4
[ 1354.145486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 1354.146465] Mem abort info:
[ 1354.146894]   ESR = 0x0000000096000006
[ 1354.148049]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1354.148754]   SET = 0, FnV = 0
[ 1354.149030]   EA = 0, S1PTW = 0
[ 1354.149429]   FSC = 0x06: level 2 translation fault
[ 1354.149948] Data abort info:
[ 1354.150278]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1354.150822]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1354.151725]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1354.152293] user pgtable: 16k pages, 36-bit VAs, pgdp=0000000045928000
[ 1354.152882] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000
[ 1354.155005] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
[ 1354.156871] Modules linked in:
[ 1354.158072] CPU: 3 PID: 289 Comm: (sd-pam) Not tainted 6.4.0-rc7-next-20230619 #1
[ 1354.160463] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[ 1354.161566] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 1354.162179] pc : __rb_erase_color+0xb8/0x24c
[ 1354.164370] lr : vma_interval_tree_remove+0x2b4/0x2c8
[ 1354.165267] sp : fffffff880b13940
[ 1354.165648] x29: fffffff880b13940 x28: fffffff001b81c30 x27: 0000000000000001
[ 1354.166570] x26: fffffff001b81760 x25: 0000000f9c000000 x24: ffffffffffffffff
[ 1354.167722] x23: fffffff880b13a98 x22: 0000000000000000 x21: fffffff002d57068
[ 1354.168422] x20: fffffff00450fc10 x19: fffffffe1c02f098 x18: fffffff000705f41
[ 1354.170661] x17: fffffff001947600 x16: 0000000000000003 x15: 0000000000000001
[ 1354.171717] x14: fffffffe1d7de5d8 x13: fffffff00450fc18 x12: 0000000000000000
[ 1354.172636] x11: 000000000000000a x10: 000000000000000a x9 : 000000000000000a
[ 1354.173118] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[ 1354.173555] x5 : 00000000810000dd x4 : fffffffff004ede0 x3 : 00000000810000dd
[ 1354.174061] x2 : fffffffe1c02f098 x1 : fffffff002d57068 x0 : fffffff00450fc10
[ 1354.174684] Call trace:
[ 1354.175325]  __rb_erase_color+0xb8/0x24c
[ 1354.176114]  vma_interval_tree_remove+0x2b4/0x2c8
[ 1354.176558]  unlink_file_vma+0x54/0x94
[ 1354.176822]  free_pgtables+0xe4/0x1ac
[ 1354.177181]  exit_mmap+0x164/0x288
[ 1354.177473]  __mmput+0x40/0x140
[ 1354.177667]  mmput+0x28/0x60
[ 1354.177977]  exit_mm+0x94/0xd4
[ 1354.178362]  do_exit+0x238/0x83c
[ 1354.179301]  do_group_exit+0x70/0x98
[ 1354.179773]  get_signal+0x67c/0x708
[ 1354.180092]  do_notify_resume+0x150/0x1350
[ 1354.180597]  el0_interrupt+0x80/0x150
[ 1354.181068]  __el0_irq_handler_common+0x18/0x24
[ 1354.181438]  el0t_64_irq_handler+0x10/0x1c
[ 1354.181788]  el0t_64_irq+0x190/0x194
[ 1354.182908] Code: 394002e8 37000428 1400002c f9400a96 (394002c8) 
[ 1354.184629] ---[ end trace 0000000000000000 ]---


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2023-06-18 23:23 Stephen Rothwell
@ 2023-06-19 20:25 ` Andrew Morton
  2023-06-19 20:43 ` Will Deacon
  1 sibling, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2023-06-19 20:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Liam R. Howlett, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, 19 Jun 2023 09:23:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/mmap.c
> 
> between commit:
> 
>   606c812eb1d5 ("mm/mmap: Fix error path in do_vmi_align_munmap()")
> 
> from the origin tree and commits:
> 
>   66106c364147 ("mm: change do_vmi_align_munmap() side tree index")
>   47b1d8de18f5 ("mm/mmap: change vma iteration order in do_vmi_align_munmap()")
> 
> from the mm tree.
> 
> I fixed it up (I think - 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.
> 

Thanks, Stephen.

We'll push the series "Reduce preallocations for maple tree" into the
next -rc cycle, so this issue should go away.

These:

maple_tree-add-benchmarking-for-mas_for_each.patch
maple_tree-add-benchmarking-for-mas_prev.patch
mm-move-unmap_vmas-declaration-to-internal-header.patch
mm-change-do_vmi_align_munmap-side-tree-index.patch
mm-remove-prev-check-from-do_vmi_align_munmap.patch
maple_tree-introduce-__mas_set_range.patch
mm-remove-re-walk-from-mmap_region.patch
maple_tree-adjust-node-allocation-on-mas_rebalance.patch
maple_tree-re-introduce-entry-to-mas_preallocate-arguments.patch
mm-use-vma_iter_clear_gfp-in-nommu.patch
mm-set-up-vma-iterator-for-vma_iter_prealloc-calls.patch
maple_tree-move-mas_wr_end_piv-below-mas_wr_extend_null.patch
maple_tree-update-mas_preallocate-testing.patch
maple_tree-refine-mas_preallocate-node-calculations.patch
maple_tree-reduce-resets-during-store-setup.patch
mm-mmap-change-vma-iteration-order-in-do_vmi_align_munmap.patch


^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2023-06-18 23:23 Stephen Rothwell
  2023-06-19 20:25 ` Andrew Morton
  2023-06-19 20:43 ` Will Deacon
  0 siblings, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2023-06-18 23:23 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Liam R. Howlett, Linus Torvalds, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/mmap.c

between commit:

  606c812eb1d5 ("mm/mmap: Fix error path in do_vmi_align_munmap()")

from the origin tree and commits:

  66106c364147 ("mm: change do_vmi_align_munmap() side tree index")
  47b1d8de18f5 ("mm/mmap: change vma iteration order in do_vmi_align_munmap()")

from the mm tree.

I fixed it up (I think - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/mmap.c
index 98cda6f72605,474a0d856622..000000000000
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@@ -2398,15 -2409,27 +2396,29 @@@ do_vmi_align_munmap(struct vma_iterato
  			if (error)
  				goto end_split_failed;
  		}
 -		mas_set(&mas_detach, count);
 -		error = munmap_sidetree(next, &mas_detach);
 -		if (error)
 -			goto munmap_sidetree_failed;
 +		vma_start_write(next);
- 		mas_set_range(&mas_detach, next->vm_start, next->vm_end - 1);
 +		if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
 +			goto munmap_gather_failed;
 +		vma_mark_detached(next, true);
 +		if (next->vm_flags & VM_LOCKED)
 +			locked_vm += vma_pages(next);
  
  		count++;
+ 		if (unlikely(uf)) {
+ 			/*
+ 			 * If userfaultfd_unmap_prep returns an error the vmas
+ 			 * will remain split, but userland will get a
+ 			 * highly unexpected error anyway. This is no
+ 			 * different than the case where the first of the two
+ 			 * __split_vma fails, but we don't undo the first
+ 			 * split, despite we could. This is unlikely enough
+ 			 * failure that it's not worth optimizing it for.
+ 			 */
+ 			error = userfaultfd_unmap_prep(next, start, end, uf);
+ 
+ 			if (error)
+ 				goto userfaultfd_error;
+ 		}
  #ifdef CONFIG_DEBUG_VM_MAPLE_TREE
  		BUG_ON(next->vm_start < start);
  		BUG_ON(next->vm_start > end);
@@@ -2454,14 -2455,18 +2444,20 @@@
  		BUG_ON(count != test_count);
  	}
  #endif
- 	/* Point of no return */
 +	error = -ENOMEM;
- 	vma_iter_set(vmi, start);
+ 	while (vma_iter_addr(vmi) > start)
+ 		vma_iter_prev_range(vmi);
+ 
  	if (vma_iter_clear_gfp(vmi, start, end, GFP_KERNEL))
 -		return -ENOMEM;
 +		goto clear_tree_failed;
  
 +	mm->locked_vm -= locked_vm;
  	mm->map_count -= count;
+ 	prev = vma_iter_prev_range(vmi);
+ 	next = vma_next(vmi);
+ 	if (next)
+ 		vma_iter_prev_range(vmi);
+ 
  	/*
  	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
  	 * VM_GROWSUP VMA. Such VMAs can change their size under

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-11-07  2:52 Stephen Rothwell
  0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2022-11-07  2:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Masami Hiramatsu (Google),
	Rafael Mendonca, wuqiang

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  kernel/trace/fprobe.c

between commit:

  d05ea35e7eea ("fprobe: Check rethook_alloc() return in rethook initialization")

from Linus' tree and commit:

  7ceeb4e77fec ("kprobes,lib: kretprobe scalability improvement")

from the mm tree.

I fixed it up (the latter included the fix from the former, so I just
used the latter) 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.



-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: linux-next: manual merge of the mm tree with Linus' tree
  2022-09-06  9:01 Stephen Rothwell
@ 2022-09-06  9:21 ` Rolf Eike Beer
  0 siblings, 0 replies; 30+ messages in thread
From: Rolf Eike Beer @ 2022-09-06  9:21 UTC (permalink / raw)
  To: Andrew Morton, Stephen Rothwell
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Steven Price

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Am Dienstag, 6. September 2022, 11:01:41 CEST schrieb Stephen Rothwell:
> Hi all,
> 
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/pagewalk.c
> 
> between commit:
> 
>   8782fb61cc84 ("mm: pagewalk: Fix race between unmap and page walker")
> 
> from Linus' tree and commits:
> 
>   fa02fb928200 ("mm: pagewalk: make error checks more obvious")
>   66c217081bd0 ("mm: pagewalk: allow walk_page_range_novma() without mm")
> 
> from the mm tree.
> 
> I fixed it up (I think - 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.

Andrew,

please drop all my patches except the following 2 from your queue for now:

-mm: pagewalk: fix documentation of PTE hole handling
-mm: pagewalk: add api documentation for walk_page_range_novma()

Some of these patches are clearly outdated now with 
8782fb61cc848364e1e1599d76d3c9dd58a1cc06 being included. I'll review them in 
detail eventually and resubmit what is still relevant.

Regards,

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 313 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-09-06  9:01 Stephen Rothwell
  2022-09-06  9:21 ` Rolf Eike Beer
  0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2022-09-06  9:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Rolf Eike Beer, Steven Price

[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]

Hi all,

Today's linux-next merge of the mm tree got a conflict in:

  mm/pagewalk.c

between commit:

  8782fb61cc84 ("mm: pagewalk: Fix race between unmap and page walker")

from Linus' tree and commits:

  fa02fb928200 ("mm: pagewalk: make error checks more obvious")
  66c217081bd0 ("mm: pagewalk: allow walk_page_range_novma() without mm")

from the mm tree.

I fixed it up (I think - 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.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/pagewalk.c
index fa7a3d21a751,418717eec09e..000000000000
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@@ -108,13 -104,16 +104,16 @@@ static int walk_pmd_range(pud_t *pud, u
  
  	pmd = pmd_offset(pud, addr);
  	do {
- again:
+ 		int err;
+ 
+  again:
  		next = pmd_addr_end(addr, end);
 -		if (pmd_none(*pmd) || (!walk->vma && !walk->no_vma)) {
 +		if (pmd_none(*pmd)) {
- 			if (ops->pte_hole)
+ 			if (ops->pte_hole) {
  				err = ops->pte_hole(addr, next, depth, walk);
- 			if (err)
- 				break;
+ 				if (err)
+ 					return err;
+ 			}
  			continue;
  		}
  
@@@ -169,13 -168,16 +168,16 @@@ static int walk_pud_range(p4d_t *p4d, u
  
  	pud = pud_offset(p4d, addr);
  	do {
+ 		int err;
+ 
   again:
  		next = pud_addr_end(addr, end);
 -		if (pud_none(*pud) || (!walk->vma && !walk->no_vma)) {
 +		if (pud_none(*pud)) {
- 			if (ops->pte_hole)
+ 			if (ops->pte_hole) {
  				err = ops->pte_hole(addr, next, depth, walk);
- 			if (err)
- 				break;
+ 				if (err)
+ 					return err;
+ 			}
  			continue;
  		}
  
@@@ -447,20 -456,17 +456,21 @@@ int walk_page_range(struct mm_struct *m
  
  	vma = find_vma(walk.mm, start);
  	do {
+ 		int err;
+ 
+ 		walk.vma = vma;
  		if (!vma) { /* after the last vma */
- 			walk.vma = NULL;
  			next = end;
 +			if (ops->pte_hole)
 +				err = ops->pte_hole(start, next, -1, &walk);
  		} else if (start < vma->vm_start) { /* outside vma */
  			walk.vma = NULL;
  			next = min(end, vma->vm_start);
 +			if (ops->pte_hole)
 +				err = ops->pte_hole(start, next, -1, &walk);
  		} else { /* inside vma */
- 			walk.vma = vma;
  			next = min(end, vma->vm_end);
- 			vma = vma->vm_next;
+ 			vma = find_vma(mm, vma->vm_end);
  
  			err = walk_page_test(start, next, &walk);
  			if (err > 0) {
@@@ -472,17 -478,26 +482,24 @@@
  				continue;
  			}
  			if (err < 0)
- 				break;
+ 				return err;
 -		}
 -		if (walk.vma || walk.ops->pte_hole) {
  			err = __walk_page_range(start, next, &walk);
+ 			if (err)
+ 				return err;
  		}
- 		if (err)
- 			break;
  	} while (start = next, start < end);
- 	return err;
+ 	return 0;
  }
  
- /*
+ /**
+  * walk_page_range_novma - walk a range of pagetables not backed by a vma
+  * @mm:		mm_struct representing the target process of page table walk
+  * @start:	start address of the virtual address range
+  * @end:	end address of the virtual address range
+  * @ops:	operation to call during the walk
+  * @pgd:	pgd to walk if different from mm->pgd
+  * @private:	private data for callbacks' usage
+  *
   * Similar to walk_page_range() but can walk any page tables even if they are
   * not backed by VMAs. Because 'unusual' entries may be walked this function
   * will also not lock the PTEs for the pte_entry() callback. This is useful for
@@@ -501,10 -518,11 +520,11 @@@ int walk_page_range_novma(struct mm_str
  		.no_vma		= true
  	};
  
- 	if (start >= end || !walk.mm)
+ 	if (start >= end || (!walk.mm && !walk.pgd))
  		return -EINVAL;
  
- 	mmap_assert_write_locked(walk.mm);
+ 	if (walk.mm)
 -		mmap_assert_locked(walk.mm);
++		mmap_assert_write_locked(walk.mm);
  
  	return walk_pgd_range(start, end, &walk);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* linux-next: manual merge of the mm tree with Linus' tree
@ 2022-05-26  6:09 Stephen Rothwell
  0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2022-05-26  6:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Oliver Glitta, Vlastimil Babka

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hi all,

Today's linux-next merge of the mm tree got conflicts in:

  init/Kconfig
  lib/Kconfig.debug

between commit:

  5cf909c553e9 ("mm/slub: use stackdepot to save stack trace in objects")

from Linus' tree and commit:

  21445ae47041 ("mm: Kconfig: reorganize misplaced mm options")

from the mm tree.

I fixed it up (I used the latter version of this file and applied the
following merge fix patch) 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 26 May 2022 16:05:37 +1000
Subject: [PATCH] fix up for "mm: Kconfig: reorganize misplaced mm options"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/Kconfig.debug | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 197eb287bf82..ce8dded36de9 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -57,6 +57,7 @@ config SLUB_DEBUG
 	default y
 	bool "Enable SLUB debugging support" if EXPERT
 	depends on SLUB && SYSFS
+	select STACKDEPOT if STACKTRACE_SUPPORT
 	help
 	  SLUB has extensive debug support features. Disabling these can
 	  result in significant savings in code size. This also disables
@@ -66,6 +67,7 @@ config SLUB_DEBUG
 config SLUB_DEBUG_ON
 	bool "SLUB debugging on by default"
 	depends on SLUB && SLUB_DEBUG
+	select STACKDEPOT_ALWAYS_INIT if STACKTRACE_SUPPORT
 	default n
 	help
 	  Boot with debugging on by default. SLUB boots by default with
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2023-07-28  3:13 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-24 23:39 linux-next: manual merge of the mm tree with Linus' tree Stephen Rothwell
2023-02-25  2:04 ` Andrew Morton
2023-02-25  7:13   ` Christian Brauner
2023-02-25 20:52     ` Andrew Morton
2023-02-27 10:18       ` Christian Brauner
2023-02-27 17:55         ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2023-07-27 23:18 Stephen Rothwell
2023-07-27 23:29 ` Stephen Rothwell
2023-07-27 23:40   ` Suren Baghdasaryan
2023-07-27 23:50     ` Matthew Wilcox
2023-07-28  0:08       ` Suren Baghdasaryan
2023-07-28  0:00   ` Stephen Rothwell
2023-07-28  3:13     ` Matthew Wilcox
2023-07-27 23:49 ` Matthew Wilcox
2023-07-28  0:21   ` Stephen Rothwell
2023-07-28  0:23     ` Suren Baghdasaryan
2023-07-28  0:29       ` Stephen Rothwell
2023-07-28  0:30         ` Suren Baghdasaryan
2023-07-06 22:54 Stephen Rothwell
2023-07-07  4:52 ` Baoquan He
2023-06-18 23:23 Stephen Rothwell
2023-06-19 20:25 ` Andrew Morton
2023-06-19 20:43 ` Will Deacon
2023-06-19 21:39   ` Andrew Morton
2023-06-20  9:43     ` Will Deacon
2023-06-20 15:00       ` Jain, Ayush
2022-11-07  2:52 Stephen Rothwell
2022-09-06  9:01 Stephen Rothwell
2022-09-06  9:21 ` Rolf Eike Beer
2022-05-26  6:09 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).