Hi all,
Today's linux-next merge of the block tree got a conflict in:
block/bio.c
between commits:
35006342b739 ("block: ensure iov_iter advances for added pages")
248022ffae3f ("block: ensure bio_iov_add_page can't fail")
7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")
from the vfs tree and commits:
5a044eef1265 ("block: ensure iov_iter advances for added pages")
ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")
from the block tree.
Commits 35006342b739 and 5a044eef1265 are the same patch as are
248022ffae3f and ac3c48e32c04. Commits 7b1ccdf617ca and 44b6b0b0e980
are slightly different. Then 9a6469060316 touches the same code :-(
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 block/bio.c
index d3bc05ed0783,6659442eb101..000000000000
--- a/block/bio.c
+++ b/block/bio.c
@@@ -1199,8 -1199,8 +1199,8 @@@ static int __bio_iov_iter_get_pages(str
struct bio_vec *bv = bio->bi_io_vec + bio->bi_vcnt;
struct page **pages = (struct page **)bv;
ssize_t size, left;
- unsigned len, i;
+ unsigned len, i = 0;
- size_t offset;
+ size_t offset, trim;
int ret = 0;
/*
On 7/13/22 8:08 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the block tree got a conflict in:
>
> block/bio.c
>
> between commits:
>
> 35006342b739 ("block: ensure iov_iter advances for added pages")
> 248022ffae3f ("block: ensure bio_iov_add_page can't fail")
> 7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
> 9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")
>
> from the vfs tree and commits:
>
> 5a044eef1265 ("block: ensure iov_iter advances for added pages")
> ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
> 44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")
>
> from the block tree.
I pinged Al about this the other day, but haven't heard back yet. It's
not clear to me what block bits he has in his tree. We'll get it sorted
out.
--
Jens Axboe
On Thu, Jul 14, 2022 at 10:36:35AM -0600, Jens Axboe wrote:
> On 7/13/22 8:08 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the block tree got a conflict in:
> >
> > block/bio.c
> >
> > between commits:
> >
> > 35006342b739 ("block: ensure iov_iter advances for added pages")
> > 248022ffae3f ("block: ensure bio_iov_add_page can't fail")
> > 7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
> > 9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")
> >
> > from the vfs tree and commits:
> >
> > 5a044eef1265 ("block: ensure iov_iter advances for added pages")
> > ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
> > 44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")
> >
> > from the block tree.
>
> I pinged Al about this the other day, but haven't heard back yet. It's
> not clear to me what block bits he has in his tree. We'll get it sorted
> out.
Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
one of the commits in it got changed since then - the difference in
__bio_iov_iter_get_pages() (unsigned int i initialization).
Sigh... I'll rebase on top of that.
Al, digging through the vicinity of propagate_umount() and cursing himself
and ebiederman in about equal proportions since the last weekend...
On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
> one of the commits in it got changed since then - the difference in
> __bio_iov_iter_get_pages() (unsigned int i initialization).
>
> Sigh... I'll rebase on top of that.
Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
Hi Al,
On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <[email protected]> wrote:
>
> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
>
> > Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
> > one of the commits in it got changed since then - the difference in
> > __bio_iov_iter_get_pages() (unsigned int i initialization).
> >
> > Sigh... I'll rebase on top of that.
>
> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
BTW, these still cause a conflict. As long as you are sharing patches
(and then adding changes to the same areas), there will be conflicts.
You need to share commits i.e. a shared branch.
--
Cheers,
Stephen Rothwell
On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
> Hi Al,
>
> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <[email protected]> wrote:
> >
> > On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> >
> > > Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
> > > one of the commits in it got changed since then - the difference in
> > > __bio_iov_iter_get_pages() (unsigned int i initialization).
> > >
> > > Sigh... I'll rebase on top of that.
> >
> > Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
>
> BTW, these still cause a conflict. As long as you are sharing patches
> (and then adding changes to the same areas), there will be conflicts.
> You need to share commits i.e. a shared branch.
Sigh... That was (and is) a branch form Keith's tree. Commits in block
tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
added.
I'm fine with using that, just tell me how to refer to the branch in
question. Jens?
On 7/17/22 10:58 PM, Al Viro wrote:
> On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
>> Hi Al,
>>
>> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <[email protected]> wrote:
>>>
>>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
>>>
>>>> Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
>>>> one of the commits in it got changed since then - the difference in
>>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
>>>>
>>>> Sigh... I'll rebase on top of that.
>>>
>>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
>>
>> BTW, these still cause a conflict. As long as you are sharing patches
>> (and then adding changes to the same areas), there will be conflicts.
>> You need to share commits i.e. a shared branch.
>
> Sigh... That was (and is) a branch form Keith's tree. Commits in block
> tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
> added.
>
> I'm fine with using that, just tell me how to refer to the branch in
> question. Jens?
Are you fine with rebasing that one again? Seems the better approach
since it's all in one spot. The git location is:
git://git.kernel.dk/linux-block for-5.20/block-iter
which has all of them, and is the same base as the previous one. Do you
want a signed tag, or is the branch fine?
--
Jens Axboe
On Tue, Jul 19, 2022 at 10:52:12AM -0600, Jens Axboe wrote:
> On 7/17/22 10:58 PM, Al Viro wrote:
> > On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
> >> Hi Al,
> >>
> >> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <[email protected]> wrote:
> >>>
> >>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> >>>
> >>>> Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
> >>>> one of the commits in it got changed since then - the difference in
> >>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
> >>>>
> >>>> Sigh... I'll rebase on top of that.
> >>>
> >>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
> >>
> >> BTW, these still cause a conflict. As long as you are sharing patches
> >> (and then adding changes to the same areas), there will be conflicts.
> >> You need to share commits i.e. a shared branch.
> >
> > Sigh... That was (and is) a branch form Keith's tree. Commits in block
> > tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
> > added.
> >
> > I'm fine with using that, just tell me how to refer to the branch in
> > question. Jens?
>
> Are you fine with rebasing that one again? Seems the better approach
> since it's all in one spot. The git location is:
>
> git://git.kernel.dk/linux-block for-5.20/block-iter
>
> which has all of them, and is the same base as the previous one. Do you
> want a signed tag, or is the branch fine?
Grabbed, rebased and force-pushed (identical tree object, so probably hadn't
fucked it up...)
On 7/19/22 8:45 PM, Al Viro wrote:
> On Tue, Jul 19, 2022 at 10:52:12AM -0600, Jens Axboe wrote:
>> On 7/17/22 10:58 PM, Al Viro wrote:
>>> On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
>>>> Hi Al,
>>>>
>>>> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <[email protected]> wrote:
>>>>>
>>>>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
>>>>>
>>>>>> Ones from Keith's branch - #alignment-fixes-rebased in there. Looks like
>>>>>> one of the commits in it got changed since then - the difference in
>>>>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
>>>>>>
>>>>>> Sigh... I'll rebase on top of that.
>>>>>
>>>>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
>>>>
>>>> BTW, these still cause a conflict. As long as you are sharing patches
>>>> (and then adding changes to the same areas), there will be conflicts.
>>>> You need to share commits i.e. a shared branch.
>>>
>>> Sigh... That was (and is) a branch form Keith's tree. Commits in block
>>> tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
>>> added.
>>>
>>> I'm fine with using that, just tell me how to refer to the branch in
>>> question. Jens?
>>
>> Are you fine with rebasing that one again? Seems the better approach
>> since it's all in one spot. The git location is:
>>
>> git://git.kernel.dk/linux-block for-5.20/block-iter
>>
>> which has all of them, and is the same base as the previous one. Do you
>> want a signed tag, or is the branch fine?
>
> Grabbed, rebased and force-pushed (identical tree object, so probably
> hadn't fucked it up...)
Great, thanks Al.
--
Jens Axboe