Re: [Xen-devel] [xen-4.1-testing test] 14689: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.12.12 at 12:45, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 14689 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14689/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-qemut-rhel6hvm-amd 11 leak-check/check    fail REGR. vs. 
> 14679
>  test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 
> 14679
>  test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 
> 14679
>  test-amd64-i386-rhel6hvm-intel 11 leak-check/check        fail REGR. vs. 
> 14679
>  test-amd64-i386-xl-multivcpu 18 leak-check/check          fail REGR. vs. 
> 14679
>  test-amd64-i386-xl           18 leak-check/check          fail REGR. vs. 
> 14679
>  test-i386-i386-xl            18 leak-check/check          fail REGR. vs. 
> 14679
>  test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 
> 14679
>  test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check    fail REGR. vs. 
> 14679
>  test-amd64-i386-rhel6hvm-amd 11 leak-check/check          fail REGR. vs. 
> 14679
>  test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 
> 14679

So this is what really should not have happened past the
intended-to-be-final RC.

> ------------------------------------------------------------
> changeset:   23428:93e17b0cd035
> tag:         tip
> user:        Greg Wettstein <greg@xxxxxxxxxxxx>
> date:        Thu Dec 13 14:35:58 2012 +0000
>     
>     libxl: avoid blktap2 deadlock on cleanup
>     
>     Establishes correct cleanup behavior for blktap devices.  This patch
>     implements the release of the backend device before calling for
>     the destruction of the userspace component of the blktap device.
>     
>     Without this patch the kernel xen-blkback driver deadlocks with
>     the blktap2 user control plane until the IPC channel is terminated by 
> the
>     timeout on the select() call.  This results in a noticeable delay
>     in the termination of the guest and causes the blktap minor
>     number which had been allocated to be orphaned.
>     
>     Signed-off-by: Greg Wettstein <greg@xxxxxxxxxxxx>
>     Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>     Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>     Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

How important is this change really to the 4.1 tree? I'd obviously
favor outright reverting it at this point (my understanding being
that the removal of the call to xs_rm() from libxl__device_destroy()
affected more than just tapdisk backends, which I guess was
assumed to be the case because of its neighboring with the call
to libxl__device_destroy_tapdisk()). Would that get the tree into
worse state that 4.1.3 was in?

Jan


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