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);
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/[email protected]
thanks,
--
John Hubbard
NVIDIA
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
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
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
On Fri, 2 Sep 2022 00:02:19 -0700 John Hubbard <[email protected]> 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.