linux-next: manual merge of the block tree with the mm tree

linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

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

  io_uring/io_uring.c

between commit:

  d3329b3a9d72 ("mm: switch mm->get_unmapped_area() to a flag")

from the mm-unstable branhc of the mm tree and commit:

  624d801ce45b ("io_uring: move mapping/allocation helpers to a separate file")

from the block 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: Tue, 2 Apr 2024 11:25:46 +1100
Subject: [PATCH] fix up for "mm: switch mm->get_unmapped_area() to a flag"

from the mm tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 io_uring/memmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/memmap.c b/io_uring/memmap.c
index acf5e8ca6b28..5c9e70132cd1 100644
--- a/io_uring/memmap.c
+++ b/io_uring/memmap.c
@@ -302,7 +302,7 @@ unsigned long io_uring_get_unmapped_area(struct file *filp, unsigned long addr,
 #else
 	addr = 0UL;
 #endif
-	return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
+	return mm_get_unmapped_area(current->mm, filp, addr, len, pgoff, flags);
 }
 
 #else /* !CONFIG_MMU */
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Tue, 2 Apr 2024 11:27:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   io_uring/io_uring.c
> 
> between commit:
> 
>   d3329b3a9d72 ("mm: switch mm->get_unmapped_area() to a flag")
> 
> from the mm-unstable branhc of the mm tree and commit:
> 
>   624d801ce45b ("io_uring: move mapping/allocation helpers to a separate file")
> 
> from the block 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: Tue, 2 Apr 2024 11:25:46 +1100
> Subject: [PATCH] fix up for "mm: switch mm->get_unmapped_area() to a flag"
> 
> from the mm tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  io_uring/memmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/io_uring/memmap.c b/io_uring/memmap.c
> index acf5e8ca6b28..5c9e70132cd1 100644
> --- a/io_uring/memmap.c
> +++ b/io_uring/memmap.c
> @@ -302,7 +302,7 @@ unsigned long io_uring_get_unmapped_area(struct file *filp, unsigned long addr,
>  #else
>  	addr = 0UL;
>  #endif
> -	return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
> +	return mm_get_unmapped_area(current->mm, filp, addr, len, pgoff, flags);
>  }
>  
>  #else /* !CONFIG_MMU */
> -- 
> 2.43.0

This is now a conflict between the mm-stable tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the block tree with the mm tree

[Edgecombe, Rick P]

On Tue, 2024-05-14 at 09:41 +1000, Stephen Rothwell wrote:
> > diff --git a/io_uring/memmap.c b/io_uring/memmap.c
> > index acf5e8ca6b28..5c9e70132cd1 100644
> > --- a/io_uring/memmap.c
> > +++ b/io_uring/memmap.c
> > @@ -302,7 +302,7 @@ unsigned long io_uring_get_unmapped_area(struct file
> > *filp, unsigned long addr,
> >   #else
> >   	addr = 0UL;
> >   #endif
> > -	return current->mm->get_unmapped_area(filp, addr, len, pgoff,
> > flags);
> > +	return mm_get_unmapped_area(current->mm, filp, addr, len, pgoff,
> > flags);
> >   }
> >   
> >   #else /* !CONFIG_MMU */
> > -- 
> > 2.43.0
> 
> This is now a conflict between the mm-stable tree and Linus' tree.

Resolution looks good to me. Andrew, do you want me to do anything here?

Re: linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Wed, 14 Feb 2024 11:25:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   include/linux/sched.h
> 
> between commit:
> 
>   d9233ee073c9 ("mm: document memalloc_noreclaim_save() and memalloc_pin_save()")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   06b23f92af87 ("block: update cached timestamp post schedule/preemption")
> 
> from the block 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 include/linux/sched.h
> index 5b27a548d863,15b7cb478d16..000000000000
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@@ -1642,9 -1641,8 +1642,9 @@@ extern struct pid *cad_pid
>   #define PF__HOLE__02000000	0x02000000
>   #define PF_NO_SETAFFINITY	0x04000000	/* Userland is not allowed to meddle with cpus_mask */
>   #define PF_MCE_EARLY		0x08000000      /* Early kill for mce process policy */
>  -#define PF_MEMALLOC_PIN		0x10000000	/* Allocation context constrained to zones which allow long term pinning. */
>  +#define PF_MEMALLOC_PIN		0x10000000	/* Allocations constrained to zones which allow long term pinning.
>  +						 * See memalloc_pin_save() */
> - #define PF__HOLE__20000000	0x20000000
> + #define PF_BLOCK_TS		0x20000000	/* plug has ts that needs updating */
>   #define PF__HOLE__40000000	0x40000000
>   #define PF_SUSPEND_TASK		0x80000000      /* This thread called freeze_processes() and should not be frozen */
>   

This is now a conflict between the mm-stable tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/sched.h

between commit:

  d9233ee073c9 ("mm: document memalloc_noreclaim_save() and memalloc_pin_save()")

from the mm-unstable branch of the mm tree and commit:

  06b23f92af87 ("block: update cached timestamp post schedule/preemption")

from the block 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 include/linux/sched.h
index 5b27a548d863,15b7cb478d16..000000000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -1642,9 -1641,8 +1642,9 @@@ extern struct pid *cad_pid
  #define PF__HOLE__02000000	0x02000000
  #define PF_NO_SETAFFINITY	0x04000000	/* Userland is not allowed to meddle with cpus_mask */
  #define PF_MCE_EARLY		0x08000000      /* Early kill for mce process policy */
 -#define PF_MEMALLOC_PIN		0x10000000	/* Allocation context constrained to zones which allow long term pinning. */
 +#define PF_MEMALLOC_PIN		0x10000000	/* Allocations constrained to zones which allow long term pinning.
 +						 * See memalloc_pin_save() */
- #define PF__HOLE__20000000	0x20000000
+ #define PF_BLOCK_TS		0x20000000	/* plug has ts that needs updating */
  #define PF__HOLE__40000000	0x40000000
  #define PF_SUSPEND_TASK		0x80000000      /* This thread called freeze_processes() and should not be frozen */
  

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

Re: linux-next: manual merge of the block tree with the mm tree

[Vishal Moola]

On Thu, Jun 15, 2023 at 6:59 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the block tree got a conflict in:
>
>   mm/gup.c
>
> between commit:
>
>   0f3f569eca46 ("mm/gup.c: reorganize try_get_folio()")
>
> from the mm tree and commit:
>
>   c8070b787519 ("mm: Don't pin ZERO_PAGE in pin_user_pages()")
>
> from the block 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 for fixing these up. I'll keep an eye out for conflicts in
linux-next as well
in the future.

Re: linux-next: manual merge of the block tree with the mm tree

[Jens Axboe]

On 6/16/23 3:56?AM, David Howells wrote:
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
>> That's getting a bit nasty.  Maybe David's patches are in the wrong
>> tree.
> 
> You'd need to discuss that one with Jens.  The patches you'd have to
> transfer also touch a number of block-related files.  Looking at
> block/for-next, there don't seem to be many other patches touching
> those files, but I've seen patches from Christoph that will need to be
> applied on top of mine.

It's definitely a bit of a mess now, but for-6.5/block also depends on
these changes and make further tweaks on the block front.

for-6.5/splice is stable, so just pull that in?

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with the mm tree

[David Howells]

Andrew Morton <akpm@linux-foundation.org> wrote:

> That's getting a bit nasty.  Maybe David's patches are in the wrong tree.

You'd need to discuss that one with Jens.  The patches you'd have to transfer
also touch a number of block-related files.  Looking at block/for-next, there
don't seem to be many other patches touching those files, but I've seen
patches from Christoph that will need to be applied on top of mine.

David

Re: linux-next: manual merge of the block tree with the mm tree

[Andrew Morton]

On Fri, 16 Jun 2023 11:58:56 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the block tree got a conflict in:
> 
>   mm/gup.c
> 
> between commit:
> 
>   0f3f569eca46 ("mm/gup.c: reorganize try_get_folio()")
> 
> from the mm tree and commit:
> 
>   c8070b787519 ("mm: Don't pin ZERO_PAGE in pin_user_pages()")
> 
> from the block 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.

That's getting a bit nasty.  Maybe David's patches are in the wrong tree.

linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  mm/gup.c

between commit:

  0f3f569eca46 ("mm/gup.c: reorganize try_get_folio()")

from the mm tree and commit:

  c8070b787519 ("mm: Don't pin ZERO_PAGE in pin_user_pages()")

from the block 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/gup.c
index ce14d4d28503,0814576b7366..000000000000
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -132,50 -127,62 +133,57 @@@ struct folio *try_grab_folio(struct pag
  	if (unlikely(!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page)))
  		return NULL;
  
 +	folio = try_get_folio(page, refs);
 +
  	if (flags & FOLL_GET)
 -		return try_get_folio(page, refs);
 -	else if (flags & FOLL_PIN) {
 -		struct folio *folio;
 -
 -		/*
 -		 * Don't take a pin on the zero page - it's not going anywhere
 -		 * and it is used in a *lot* of places.
 -		 */
 -		if (is_zero_page(page))
 -			return page_folio(page);
 -
 -		/*
 -		 * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a
 -		 * right zone, so fail and let the caller fall back to the slow
 -		 * path.
 -		 */
 -		if (unlikely((flags & FOLL_LONGTERM) &&
 -			     !is_longterm_pinnable_page(page)))
 -			return NULL;
 -
 -		/*
 -		 * CAUTION: Don't use compound_head() on the page before this
 -		 * point, the result won't be stable.
 -		 */
 -		folio = try_get_folio(page, refs);
 -		if (!folio)
 -			return NULL;
 -
 -		/*
 -		 * When pinning a large folio, use an exact count to track it.
 -		 *
 -		 * However, be sure to *also* increment the normal folio
 -		 * refcount field at least once, so that the folio really
 -		 * is pinned.  That's why the refcount from the earlier
 -		 * try_get_folio() is left intact.
 -		 */
 -		if (folio_test_large(folio))
 -			atomic_add(refs, &folio->_pincount);
 -		else
 -			folio_ref_add(folio,
 -					refs * (GUP_PIN_COUNTING_BIAS - 1));
 -		/*
 -		 * Adjust the pincount before re-checking the PTE for changes.
 -		 * This is essentially a smp_mb() and is paired with a memory
 -		 * barrier in page_try_share_anon_rmap().
 -		 */
 -		smp_mb__after_atomic();
 -
 -		node_stat_mod_folio(folio, NR_FOLL_PIN_ACQUIRED, refs);
 -
  		return folio;
 +
 +	/* FOLL_PIN is set */
 +	if (!folio)
 +		return NULL;
 +
++	/*
++	 * Don't take a pin on the zero page - it's not going anywhere
++	 * and it is used in a *lot* of places.
++	 */
++	if (is_zero_page(page))
++		return page_folio(page);
++
 +	/*
 +	 * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a
 +	 * right zone, so fail and let the caller fall back to the slow
 +	 * path.
 +	 */
 +	if (unlikely((flags & FOLL_LONGTERM) &&
 +		     !folio_is_longterm_pinnable(folio))) {
 +		if (!put_devmap_managed_page_refs(&folio->page, refs))
 +			folio_put_refs(folio, refs);
 +		return NULL;
  	}
  
 -	WARN_ON_ONCE(1);
 -	return NULL;
 +	/*
 +	 * When pinning a large folio, use an exact count to track it.
 +	 *
 +	 * However, be sure to *also* increment the normal folio
 +	 * refcount field at least once, so that the folio really
 +	 * is pinned.  That's why the refcount from the earlier
 +	 * try_get_folio() is left intact.
 +	 */
 +	if (folio_test_large(folio))
 +		atomic_add(refs, &folio->_pincount);
 +	else
 +		folio_ref_add(folio,
 +				refs * (GUP_PIN_COUNTING_BIAS - 1));
 +	/*
 +	 * Adjust the pincount before re-checking the PTE for changes.
 +	 * This is essentially a smp_mb() and is paired with a memory
 +	 * barrier in page_try_share_anon_rmap().
 +	 */
 +	smp_mb__after_atomic();
 +
 +	node_stat_mod_folio(folio, NR_FOLL_PIN_ACQUIRED, refs);
 +
 +	return folio;
  }
  
  static void gup_put_folio(struct folio *folio, int refs, unsigned int flags)
@@@ -3250,9 -3193,13 +3300,12 @@@ EXPORT_SYMBOL(pin_user_pages_remote)
   *
   * FOLL_PIN means that the pages must be released via unpin_user_page(). Please
   * see Documentation/core-api/pin_user_pages.rst for details.
+  *
+  * Note that if a zero_page is amongst the returned pages, it will not have
+  * pins in it and unpin_user_page*() will not remove pins from it.
   */
  long pin_user_pages(unsigned long start, unsigned long nr_pages,
 -		    unsigned int gup_flags, struct page **pages,
 -		    struct vm_area_struct **vmas)
 +		    unsigned int gup_flags, struct page **pages)
  {
  	int locked = 1;
  

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

linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/mm.h

between commit:

  3ed01074f441 ("mm: remove is_longterm_pinnable_page() and Reimplement folio_is_longterm_pinnable()")

from the mm tree and commit:

  c8070b787519 ("mm: Don't pin ZERO_PAGE in pin_user_pages()")

from the block tree.

I fixed it up (I thinkl - 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 include/linux/mm.h
index e3e047735ccc,200068d98686..000000000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -1902,18 -1910,40 +1902,40 @@@ static inline bool page_needs_cow_for_d
  	return page_maybe_dma_pinned(page);
  }
  
+ /**
+  * is_zero_page - Query if a page is a zero page
+  * @page: The page to query
+  *
+  * This returns true if @page is one of the permanent zero pages.
+  */
+ static inline bool is_zero_page(const struct page *page)
+ {
+ 	return is_zero_pfn(page_to_pfn(page));
+ }
+ 
+ /**
+  * is_zero_folio - Query if a folio is a zero page
+  * @folio: The folio to query
+  *
+  * This returns true if @folio is one of the permanent zero pages.
+  */
+ static inline bool is_zero_folio(const struct folio *folio)
+ {
+ 	return is_zero_page(&folio->page);
+ }
+ 
 -/* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
 +/* MIGRATE_CMA and ZONE_MOVABLE do not allow pin folios */
  #ifdef CONFIG_MIGRATION
 -static inline bool is_longterm_pinnable_page(struct page *page)
 +static inline bool folio_is_longterm_pinnable(struct folio *folio)
  {
  #ifdef CONFIG_CMA
 -	int mt = get_pageblock_migratetype(page);
 +	int mt = folio_migratetype(folio);
  
  	if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
  		return false;
  #endif
- 	/* The zero page may always be pinned */
- 	if (is_zero_pfn(folio_pfn(folio)))
+ 	/* The zero page can be "pinned" but gets special handling. */
 -	if (is_zero_page(page))
++	if (is_zero_folio(folio))
  		return true;
  
  	/* Coherent device memory must always allow eviction. */

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

Re: linux-next: manual merge of the block tree with the mm tree

[Jens Axboe]

On 3/22/23 5:26?PM, Andrew Morton wrote:
> On Wed, 22 Mar 2023 17:15:48 -0600 Jens Axboe <axboe@kernel.dk> wrote:
> 
>> On 3/22/23 5:13?PM, David Howells wrote:
>>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>>  +	if (unlikely(iov_iter_is_pipe(i))) {
>>>>  +		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
>>>>  +		goto out;
>>>>  +	}
>>>
>>> This bit would need to be removed from copy_page_to_iter_atomic() as the two
>>> functions it calls should be removed by the patch in the block tree.
>>
>> Maybe it'd be better to consolidate rather than split the changes over
>> two trees?
> 
> fyi, Lorenzo has sent out v7 of this series.  I'll be pushing this in
> an hour or so.  After which I suggest Stephen removes those (now) two
> lines and sends out one of his "build fix" emails which can be the
> basis for Linus's resolution.
> 
> Or I can just steal "iov_iter: Kill ITER_PIPE"...

Or how about we just make sure to queue up items that touch them same
stuff in the same tree? I've already had this queued for a week, and
seems pretty silly to shuffle things around because some thing got
posted in 4 iterations today and then queued up right after.

Plus the build is now broken, so maybe a bit more diligence would be
required here than the drive-by-merging.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with the mm tree

[David Howells]

Andrew Morton <akpm@linux-foundation.org> wrote:

> Or I can just steal "iov_iter: Kill ITER_PIPE"...

You'd need to steal the eight patches before it too.

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/log/?h=for-6.4/splice

	iov_iter: Kill ITER_PIPE
	cifs: Use generic_file_splice_read()	
	splice: Do splice read from a file without using ITER_PIPE
	tty, proc, kernfs, random: Use direct_splice_read()	
	coda: Implement splice-read	
	overlayfs: Implement splice-read
	shmem: Implement splice-read	
	splice: Make do_splice_to() generic and export it
	splice: Clean up direct_splice_read() a bit

David

Re: linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Wed, 22 Mar 2023 16:26:38 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> fyi, Lorenzo has sent out v7 of this series.  I'll be pushing this in
> an hour or so.  After which I suggest Stephen removes those (now) two
> lines and sends out one of his "build fix" emails which can be the
> basis for Linus's resolution.

I have not picked up v7 (I will get that tomorrow), but I have gone
back in today's tree and changed the merge resolution to be as below.
-- 
Cheers,
Stephen Rothwell

diff --cc lib/iov_iter.c
index 48ca1c5dfc04,fad95e4cf372..389cc8a53097
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@@ -821,60 -532,6 +532,29 @@@ size_t copy_page_from_iter_atomic(struc
  }
  EXPORT_SYMBOL(copy_page_from_iter_atomic);
  
 +size_t copy_page_to_iter_atomic(struct page *page, unsigned offset, size_t bytes,
 +				struct iov_iter *i)
 +{
 +	char *kaddr = kmap_local_page(page);
 +	char *p = kaddr + offset;
 +	size_t copied = 0;
 +
 +	if (!page_copy_sane(page, offset, bytes) ||
 +	    WARN_ON_ONCE(i->data_source))
 +		goto out;
 +
- 	if (unlikely(iov_iter_is_pipe(i))) {
- 		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
- 		goto out;
- 	}
- 
 +	iterate_and_advance(i, bytes, base, len, off,
 +		copyout(base, p + off, len),
 +		memcpy(base, p + off, len)
 +	)
 +	copied = bytes;
 +
 +out:
 +	kunmap_local(kaddr);
 +	return copied;
 +}
 +EXPORT_SYMBOL(copy_page_to_iter_atomic);
 +
- static void pipe_advance(struct iov_iter *i, size_t size)
- {
- 	struct pipe_inode_info *pipe = i->pipe;
- 	int off = i->last_offset;
- 
- 	if (!off && !size) {
- 		pipe_discard_from(pipe, i->start_head); // discard everything
- 		return;
- 	}
- 	i->count -= size;
- 	while (1) {
- 		struct pipe_buffer *buf = pipe_buf(pipe, i->head);
- 		if (off) /* make it relative to the beginning of buffer */
- 			size += abs(off) - buf->offset;
- 		if (size <= buf->len) {
- 			buf->len = size;
- 			i->last_offset = last_offset(buf);
- 			break;
- 		}
- 		size -= buf->len;
- 		i->head++;
- 		off = 0;
- 	}
- 	pipe_discard_from(pipe, i->head + 1); // discard everything past this one
- }
- 
  static void iov_iter_bvec_advance(struct iov_iter *i, size_t size)
  {
  	const struct bio_vec *bvec, *end;

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

Re: linux-next: manual merge of the block tree with the mm tree

[Andrew Morton]

On Wed, 22 Mar 2023 17:15:48 -0600 Jens Axboe <axboe@kernel.dk> wrote:

> On 3/22/23 5:13 PM, David Howells wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> >>  +	if (unlikely(iov_iter_is_pipe(i))) {
> >>  +		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
> >>  +		goto out;
> >>  +	}
> > 
> > This bit would need to be removed from copy_page_to_iter_atomic() as the two
> > functions it calls should be removed by the patch in the block tree.
> 
> Maybe it'd be better to consolidate rather than split the changes over
> two trees?

fyi, Lorenzo has sent out v7 of this series.  I'll be pushing this in
an hour or so.  After which I suggest Stephen removes those (now) two
lines and sends out one of his "build fix" emails which can be the
basis for Linus's resolution.

Or I can just steal "iov_iter: Kill ITER_PIPE"...





From: Lorenzo Stoakes <lstoakes@gmail.com>
Subject: iov_iter: add copy_page_to_iter_nofault()
Date: Wed, 22 Mar 2023 18:57:03 +0000

Provide a means to copy a page to user space from an iterator, aborting if
a page fault would occur.  This supports compound pages, but may be passed
a tail page with an offset extending further into the compound page, so we
cannot pass a folio.

This allows for this function to be called from atomic context and _try_
to user pages if they are faulted in, aborting if not.

The function does not use _copy_to_iter() in order to not specify
might_fault(), this is similar to copy_page_from_iter_atomic().

This is being added in order that an iteratable form of vread() can be
implemented while holding spinlocks.

Link: https://lkml.kernel.org/r/19734729defb0f498a76bdec1bef3ac48a3af3e8.1679511146.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Baoquan He <bhe@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Liu Shixin <liushixin2@huawei.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---


--- a/include/linux/uio.h~iov_iter-add-copy_page_to_iter_nofault
+++ a/include/linux/uio.h
@@ -173,6 +173,8 @@ static inline size_t copy_folio_to_iter(
 {
 	return copy_page_to_iter(&folio->page, offset, bytes, i);
 }
+size_t copy_page_to_iter_nofault(struct page *page, unsigned offset,
+				 size_t bytes, struct iov_iter *i);
 
 static __always_inline __must_check
 size_t copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i)
--- a/lib/iov_iter.c~iov_iter-add-copy_page_to_iter_nofault
+++ a/lib/iov_iter.c
@@ -172,6 +172,18 @@ static int copyout(void __user *to, cons
 	return n;
 }
 
+static int copyout_nofault(void __user *to, const void *from, size_t n)
+{
+	long res;
+
+	if (should_fail_usercopy())
+		return n;
+
+	res = copy_to_user_nofault(to, from, n);
+
+	return res < 0 ? n : res;
+}
+
 static int copyin(void *to, const void __user *from, size_t n)
 {
 	size_t res = n;
@@ -734,6 +746,42 @@ size_t copy_page_to_iter(struct page *pa
 }
 EXPORT_SYMBOL(copy_page_to_iter);
 
+size_t copy_page_to_iter_nofault(struct page *page, unsigned offset, size_t bytes,
+				 struct iov_iter *i)
+{
+	size_t res = 0;
+
+	if (!page_copy_sane(page, offset, bytes))
+		return 0;
+	if (WARN_ON_ONCE(i->data_source))
+		return 0;
+	if (unlikely(iov_iter_is_pipe(i)))
+		return copy_page_to_iter_pipe(page, offset, bytes, i);
+	page += offset / PAGE_SIZE; // first subpage
+	offset %= PAGE_SIZE;
+	while (1) {
+		void *kaddr = kmap_local_page(page);
+		size_t n = min(bytes, (size_t)PAGE_SIZE - offset);
+
+		iterate_and_advance(i, n, base, len, off,
+			copyout_nofault(base, kaddr + offset + off, len),
+			memcpy(base, kaddr + offset + off, len)
+		)
+		kunmap_local(kaddr);
+		res += n;
+		bytes -= n;
+		if (!bytes || !n)
+			break;
+		offset += n;
+		if (offset == PAGE_SIZE) {
+			page++;
+			offset = 0;
+		}
+	}
+	return res;
+}
+EXPORT_SYMBOL(copy_page_to_iter_nofault);
+
 size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes,
 			 struct iov_iter *i)
 {
_

Re: linux-next: manual merge of the block tree with the mm tree

[Jens Axboe]

On 3/22/23 5:13 PM, David Howells wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>>  +	if (unlikely(iov_iter_is_pipe(i))) {
>>  +		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
>>  +		goto out;
>>  +	}
> 
> This bit would need to be removed from copy_page_to_iter_atomic() as the two
> functions it calls should be removed by the patch in the block tree.

Maybe it'd be better to consolidate rather than split the changes over
two trees?

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with the mm tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>  +	if (unlikely(iov_iter_is_pipe(i))) {
>  +		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
>  +		goto out;
>  +	}

This bit would need to be removed from copy_page_to_iter_atomic() as the two
functions it calls should be removed by the patch in the block tree.

David

linux-next: manual merge of the block tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  lib/iov_iter.c

between commit:

  c4cf24ce34b7 ("iov_iter: add copy_page_to_iter_atomic()")

from the mm tree and commit:

  a53f5dee3448 ("iov_iter: Kill ITER_PIPE")

from the block 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 lib/iov_iter.c
index 48ca1c5dfc04,fad95e4cf372..000000000000
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@@ -821,60 -532,6 +532,34 @@@ size_t copy_page_from_iter_atomic(struc
  }
  EXPORT_SYMBOL(copy_page_from_iter_atomic);
  
 +size_t copy_page_to_iter_atomic(struct page *page, unsigned offset, size_t bytes,
 +				struct iov_iter *i)
 +{
 +	char *kaddr = kmap_local_page(page);
 +	char *p = kaddr + offset;
 +	size_t copied = 0;
 +
 +	if (!page_copy_sane(page, offset, bytes) ||
 +	    WARN_ON_ONCE(i->data_source))
 +		goto out;
 +
 +	if (unlikely(iov_iter_is_pipe(i))) {
 +		copied = copy_page_to_iter_pipe(page, offset, bytes, i);
 +		goto out;
 +	}
 +
 +	iterate_and_advance(i, bytes, base, len, off,
 +		copyout(base, p + off, len),
 +		memcpy(base, p + off, len)
 +	)
 +	copied = bytes;
 +
 +out:
 +	kunmap_local(kaddr);
 +	return copied;
 +}
 +EXPORT_SYMBOL(copy_page_to_iter_atomic);
 +
- static void pipe_advance(struct iov_iter *i, size_t size)
- {
- 	struct pipe_inode_info *pipe = i->pipe;
- 	int off = i->last_offset;
- 
- 	if (!off && !size) {
- 		pipe_discard_from(pipe, i->start_head); // discard everything
- 		return;
- 	}
- 	i->count -= size;
- 	while (1) {
- 		struct pipe_buffer *buf = pipe_buf(pipe, i->head);
- 		if (off) /* make it relative to the beginning of buffer */
- 			size += abs(off) - buf->offset;
- 		if (size <= buf->len) {
- 			buf->len = size;
- 			i->last_offset = last_offset(buf);
- 			break;
- 		}
- 		size -= buf->len;
- 		i->head++;
- 		off = 0;
- 	}
- 	pipe_discard_from(pipe, i->head + 1); // discard everything past this one
- }
- 
  static void iov_iter_bvec_advance(struct iov_iter *i, size_t size)
  {
  	const struct bio_vec *bvec, *end;

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