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;

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.

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

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?

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.

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.