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

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

[Stephen Rothwell]

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

Hi all,

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

  block/blk-map.c

between commit:

  e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")

from the block tree and commit:

  2e9a2aa23dad ("block, bio, fs: convert most filesystems to pin_user_pages_fast()")

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 block/blk-map.c
index f3768876d618,4e333ad9776d..000000000000
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@@ -273,14 -254,8 +273,14 @@@ static int bio_map_user_iov(struct requ
  		size_t offs, added = 0;
  		int npages;
  
 -		bytes = dio_w_iov_iter_pin_pages_alloc(iter, &pages, LONG_MAX,
 -						       &offs);
 +		if (nr_vecs <= ARRAY_SIZE(stack_pages)) {
 +			pages = stack_pages;
- 			bytes = iov_iter_get_pages2(iter, pages, LONG_MAX,
++			bytes = dio_w_iov_iter_pin_pages(iter, pages, LONG_MAX,
 +							nr_vecs, &offs);
 +		} else {
- 			bytes = iov_iter_get_pages_alloc2(iter, &pages,
++			bytes = dio_w_iov_iter_pin_pages_alloc(iter, &pages,
 +							LONG_MAX, &offs);
 +		}
  		if (unlikely(bytes <= 0)) {
  			ret = bytes ? bytes : -EFAULT;
  			goto out_unmap;
@@@ -315,9 -290,8 +315,9 @@@
  		 * release the pages we didn't map into the bio, if any
  		 */
  		while (j < npages)
- 			put_page(pages[j++]);
+ 			dio_w_unpin_user_page(pages[j++]);
 -		kvfree(pages);
 +		if (pages != stack_pages)
 +			kvfree(pages);
  		/* couldn't stuff something into bio? */
  		if (bytes) {
  			iov_iter_revert(iter, bytes);

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

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

[John Hubbard]

On 8/31/22 23:17, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   block/blk-map.c
> 
> between commit:
> 
>   e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")
> 
> from the block tree and commit:
> 
>   2e9a2aa23dad ("block, bio, fs: convert most filesystems to pin_user_pages_fast()")
> 
> from the mm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as

The fix up looks correct to me.

> 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.
> 

Of the 7 patches in my series [1], the first two are in mm, and provide
some prerequisites. The remaining patches apply to block, bio, fs, and
iov_iter, and that's where this merge conflict happened.

Also, there's still some upcoming churn (more patchset revisions are
coming), as reviews are still active and this one isn't perfected yet.

So I see two obvious solutions. Either:

a) Only do the first two patches for now, and leave them in Andrew's
tree. After the next release, do the remaining 5 patches via the block
tree, or

b) Move the whole series to the block tree now, or

c) something else?

Andrew, Jens, any preference here? 


[1] https://lore.kernel.org/r/20220831041843.973026-1-jhubbard@nvidia.com

thanks,

-- 
John Hubbard
NVIDIA

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

[Jens Axboe]

On 9/1/22 1:47 AM, John Hubbard wrote:
> On 8/31/22 23:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the mm tree got a conflict in:
>>
>>   block/blk-map.c
>>
>> between commit:
>>
>>   e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")
>>
>> from the block tree and commit:
>>
>>   2e9a2aa23dad ("block, bio, fs: convert most filesystems to pin_user_pages_fast()")
>>
>> from the mm tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as
> 
> The fix up looks correct to me.
> 
>> 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.
>>
> 
> Of the 7 patches in my series [1], the first two are in mm, and provide
> some prerequisites. The remaining patches apply to block, bio, fs, and
> iov_iter, and that's where this merge conflict happened.
> 
> Also, there's still some upcoming churn (more patchset revisions are
> coming), as reviews are still active and this one isn't perfected yet.
> 
> So I see two obvious solutions. Either:
> 
> a) Only do the first two patches for now, and leave them in Andrew's
> tree. After the next release, do the remaining 5 patches via the block
> tree, or
> 
> b) Move the whole series to the block tree now, or
> 
> c) something else?
> 
> Andrew, Jens, any preference here? 

Would've been cleaner to take through the block tree given what
it touches, imho. Or at least base on that, so we'd avoid frivolous
conflicts like this.

-- 
Jens Axboe

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

[John Hubbard]

On 9/1/22 07:10, Jens Axboe wrote:
>> So I see two obvious solutions. Either:
>>
>> a) Only do the first two patches for now, and leave them in Andrew's
>> tree. After the next release, do the remaining 5 patches via the block
>> tree, or
>>
>> b) Move the whole series to the block tree now, or
>>
>> c) something else?
>>
>> Andrew, Jens, any preference here? 
> 
> Would've been cleaner to take through the block tree given what
> it touches, imho. Or at least base on that, so we'd avoid frivolous
> conflicts like this.
> 

OK, so I'm new to block, and my first guess at the right git tree
and branch:

    git://git.kernel.dk/linux-block block-6.0

 doesn't seem to contain this one:

    e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")

Can you point me to the right tree please?

Once I know the right block tree to use, I could post the next version
rebased on top of that. And plan to send it up through Jens' block tree,
assuming that it continues to survive the reviews, that is.

Andrew, is that OK with you? The first two patches will still get
reviewed by mm, and they shouldn't conflict with mm, even if they
go up through the block tree.


thanks,

-- 
John Hubbard
NVIDIA

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

[Jens Axboe]

On 9/2/22 1:02 AM, John Hubbard wrote:
> On 9/1/22 07:10, Jens Axboe wrote:
>>> So I see two obvious solutions. Either:
>>>
>>> a) Only do the first two patches for now, and leave them in Andrew's
>>> tree. After the next release, do the remaining 5 patches via the block
>>> tree, or
>>>
>>> b) Move the whole series to the block tree now, or
>>>
>>> c) something else?
>>>
>>> Andrew, Jens, any preference here? 
>>
>> Would've been cleaner to take through the block tree given what
>> it touches, imho. Or at least base on that, so we'd avoid frivolous
>> conflicts like this.
>>
> 
> OK, so I'm new to block, and my first guess at the right git tree
> and branch:
> 
>     git://git.kernel.dk/linux-block block-6.0
> 
>  doesn't seem to contain this one:
> 
>     e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")
> 
> Can you point me to the right tree please?

That's because block-6.0 contains fixes for 6.0, it's not a 6.1 tree.
for-6.1/block is the pending 6.1 items, and for-next contains all my
branches merged for linux-next consumption.

> Once I know the right block tree to use, I could post the next version
> rebased on top of that. And plan to send it up through Jens' block tree,
> assuming that it continues to survive the reviews, that is.
> 
> Andrew, is that OK with you? The first two patches will still get
> reviewed by mm, and they shouldn't conflict with mm, even if they
> go up through the block tree.

We can just make it a separate topic branch too, I often do that for
various items that are separate in nature and has overlap.

-- 
Jens Axboe

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

[Andrew Morton]

On Fri, 2 Sep 2022 00:02:19 -0700 John Hubbard <jhubbard@nvidia.com> wrote:

> Andrew, is that OK with you? The first two patches will still get
> reviewed by mm, and they shouldn't conflict with mm, even if they
> go up through the block tree.

Sure. 

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

[Stephen Rothwell]

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

Hi all,

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

  mm/gup.c
  mm/huge_memory.c

between commits:

  0f0892356fa1 ("mm: allow multiple error returns in try_grab_page()")
  4003f107fa2e ("mm: introduce FOLL_PCI_P2PDMA to gate getting PCI P2PDMA pages")

from the block tree and commit:

  7928e6cb4ec6 ("mm/gup: drop DAX pgmap accounting")

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/gup.c
index 8a4b1a783cb6,5182abaaecde..000000000000
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -2482,26 -2394,10 +2406,13 @@@ static int __gup_device_huge(unsigned l
  	do {
  		struct page *page = pfn_to_page(pfn);
  
- 		pgmap = get_dev_pagemap(pfn, pgmap);
- 		if (unlikely(!pgmap)) {
- 			undo_dev_pagemap(nr, nr_start, flags, pages);
- 			break;
- 		}
- 
- 		if (!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page)) {
- 			undo_dev_pagemap(nr, nr_start, flags, pages);
++		if (!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page))
 +			break;
- 		}
 +
  		SetPageReferenced(page);
  		pages[*nr] = page;
- 		if (unlikely(try_grab_page(page, flags))) {
- 			undo_dev_pagemap(nr, nr_start, flags, pages);
 -		if (unlikely(!try_grab_page(page, flags)))
++		if (unlikely(try_grab_page(page, flags)))
  			break;
- 		}
  		(*nr)++;
  		pfn++;
  	} while (addr += PAGE_SIZE, addr != end);
diff --cc mm/huge_memory.c
index a075e3803e5e,ed12cd3acbfd..000000000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1225,14 -1179,9 +1180,11 @@@ struct page *follow_devmap_pud(struct v
  		return ERR_PTR(-EEXIST);
  
  	pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT;
- 	*pgmap = get_dev_pagemap(pfn, *pgmap);
- 	if (!*pgmap)
- 		return ERR_PTR(-EFAULT);
  	page = pfn_to_page(pfn);
 -	if (!try_grab_page(page, flags))
 -		page = ERR_PTR(-ENOMEM);
 +
 +	ret = try_grab_page(page, flags);
 +	if (ret)
 +		page = ERR_PTR(ret);
  
  	return page;
  }

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