lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 02 Nov 2013 15:50:11 -0500
From:	Dave Kleikamp <>
To:	Stephen Rothwell <>
CC:	Jens Axboe <>,,, Zach Brown <>,
	Kent Overstreet <>
Subject: Re: linux-next: manual merge of the block tree with the  tree

On 11/01/2013 03:53 PM, Jens Axboe wrote:
> On 11/01/2013 02:41 PM, Dave Kleikamp wrote:
>> On 11/01/2013 03:27 PM, Jens Axboe wrote:
>>> On 11/01/2013 02:22 PM, Stephen Rothwell wrote:
>>>> Hi Jens,
>>>> On Fri, 01 Nov 2013 09:10:43 -0600 Jens Axboe <> wrote:
>>>>> On 10/31/2013 09:20 PM, Stephen Rothwell wrote:
>>>>>> Today's linux-next merge of the block tree got a conflict in
>>>>>> drivers/block/loop.c between commit 2486740b52fd ("loop: use aio to
>>>>>> perform io on the underlying file") from the aio-direct tree and commit
>>>>>> ed2d2f9a8265 ("block: Abstract out bvec iterator") from the block tree.
>>>>>> I fixed it up (I think - see below - I have also attached the final
>>>>>> resulting file) and can carry the fix as necessary (no action is
>>>>>> required).
>>>>> What tree is this from? It'd be a lot more convenient to fold that loop
>>>>> patch into my tree, especially since the block tree in linux-next failed
>>>>> after this merge.
>>>> I can only agree with you.  It is from the aio-direct tree (probably
>>>> misnamed by me) (git:// run
>>>> by Dave Kleikamp.
>>> Dave, input requested.
>>> In any case, I would suggest dropping the aio-direct tree instead of the
>>> entire block tree for coverage purposes, if merge or build failures
>>> happen because of it.
>> I've had these patches in linux-next since August, and I'd really like
>> to push them in the 3.13 merge window.
>> Are there other problems besides this merge issue? I'll take a closer
>> look at Stephen's merge patch and see if I find any other issues, but I
>> really don't want to pull these patches out of linux-next now.
> I'm not saying that the patches should be dropped or not go into 3.13.
> What I'm saying is that if the choice is between having the bio and
> blk-mq stuff in linux-next or an addon to the loop driver, the decision
> should be quite clear.
> So we've three immediate options:
> 1) You base it on top of the block tree
> 2) I carry the loop updates
> 3) You hand Stephen a merge patch for the resulting merge of the two

Attached is a merge patch and the merged loop.c. I'm having problems
with the loop driver with both the block and my tree. I'll continue to
look at that, but everything should build cleanly with this.

> It's one of the problems with too-many-tree, imho. You end up with
> dependencies that could have been solved if the work had been applied in
> the right upstream tree. Sometimes that's not even enough though, if you
> end up crossing boundaries.

View attachment "loop.c" of type "text/x-csrc" (50389 bytes)

View attachment "loop.c-merge.patch" of type "text/x-patch" (4386 bytes)

Powered by blists - more mailing lists