Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block

[Ross Philipson <ross.philipson@xxxxxxxxx>]

On 03/29/2016 07:26 AM, George Dunlap wrote:
> On Fri, Mar 25, 2016 at 4:34 PM, Ross Philipson
> <ross.philipson@xxxxxxxxx> wrote:
>> On 03/25/2016 12:11 PM, Wei Liu wrote:
>>> On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote:
>>>> It seems the logic is meant to detect sector unaligned buffers for block
>>>> writes. The NOTing of the logic instead masks off any unaligned bits and
>>>> also would cause the function to always fail. It seems the function is not
>>>> used in any of the tools so that is probably why the problem is not seen.
>>>> In the vhd_read_block function it is correct.
>>>>
>>>> Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxxxx>
>>>
>>> This seems to fall under tools umbrella. I've look at blktap2 code,
>>> the reasoning is convincing to me so:
>>>
>>>   Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>>>
>>> But I've never used blktap2 and we don't normally test it so I would
>>> also wait a bit longer to see if anybody objects to this change.
>>>
>>> OOI if no code was using this, how did you discover this problem?
>>
>> We have an old fork of blktap2 from way back when. I was working to extract 
>> our
>> changes and turn them into patches so we could rebase on upstream blktap2.
>> Someone long ago found that - I have no idea how but it was a valid fix so I
>> upstreamed it.
>>
>> There are a number of other ones that were found that are still in upstream
>> blktap2 - I plan to send them too.
> 
> Ross,
> 
> Instead of cross-porting fixes from XenServer's blktap3 to the
> bitrotting blktap2, would you consider taking up my work on replacing
> blktap2 with building blktap3 as an external project?

George, sorry I had to sort out some red tape before I could reply. For the
record I am not cross porting from blktap3 but upstreaming from a very old fork
of blktap2 that came from XenServer.

But really that is of little concern because I think your idea is a really good
one. Yes I would be up for taking on that work and we would very much like to
re-base our project on blktap3 too. I cannot give you an exact date when I would
start on it but probably I could start at the beginning of May. In the mean time
I will spend time familiarizing myself with blktap3 and I will probably have
some question for you too...

Thanks

> 
> The basic shape of things that need to happen for that are:
> 
> 1. Allow qemu to provide emulated devices for disks which use hotplug
> scripts (just checked in last week)
> 
> 2. Do the tweaks necessary to allow blktap3 to be built as an
> independent project (outside the XenServer build system)
> 
> 3. Switch libxl to use the already-in-tree block-tap script (which
> calls tapctl) rather than linking against the blktap library.
> 
> 4. Add a blktap target to raisin.
> 
> #1 is done and was just checked in last week.  #2 shouldn't be a
> terribly large amount of work.  For #3, I've posted patches already,
> and I can probably do a quick rebase for you to pick up if you wanted.
> #4 shouldn't be too hard once you have an out-of-tree build working; I
> can help with that as well.
> 
> If we then add tests for upstream blktap to osstest, then we'll catch
> any breakages, and automatically get updates; and we can delete the
> bitrotting blktap2 out of the tree.
> 
> What do you think?
> 
>  -George
> 


-- 
Ross Philipson

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel