Re: [Xen-devel] blktap2 bug:Assertion 'list_empty(&vreq->next)' failed

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

On Thu, 2010-07-01 at 08:55 -0400, tsk wrote:
> Hi, will the patches be added to Xen-4.1ï

About to prepare the next bunch of patches for xen.git.

Jeremy, is it okay to pull some of the changes made for 2.6.3x into the
xen/dom0/backend/blktap2 topic branch before moving on?

I'm mainly talking about this one:

>From ab77527f9a63a5c657c6d6a50e70a66adceaa3a0 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
Date: Thu, 18 Feb 2010 17:22:09 -0800
Subject: [PATCH] xen/blktap2: make compile

and a couple related deltas which came later.

Except moving forward to newer blk queue interfaces, they don't make
much of a functional difference.

Would simplify merging quite a bit.

Daniel

> 
> 2010/6/28 Daniel Stodden <daniel.stodden@xxxxxxxxxx>
>         On Mon, 2010-06-28 at 00:58 -0400, tsk wrote:
>         > It is found that some assertion was in the tapdisk2 source,
>         if anyone
>         > failed, the tapdisk2 process will exit,
>         > They are very dangerous...
>         > How can the kernel handle this if the tapdisk2 process exit?
>         
>         
>         There would be multiple ways.
>         
>         One is to recover in-flight I/O and wait for a new tapdisk to
>         start,
>         then reissue. There's not a real usecase for this, but think
>         watchdog.
>         Maybe someday.
>         
>         The present strategy is to:
>          - Fail pending I/O.
>          - Restart the disk I/O queue, thereby flushing everything
>         submitted
>           to the block device with EIO as well.
>          - Release the block device after the last opener finally gave
>         up.
>         
>         Works well. At least from a dom0 perspective ;)
>         
>         Daniel
>         
>         
>         >
>         >
>         > 2010/6/28 Daniel Stodden <daniel.stodden@xxxxxxxxxx>
>         >         On Mon, 2010-06-28 at 00:41 -0400, tsk wrote:
>         >         > Hi folks,
>         >         >
>         >         >
>         >         > Yestoday, I run a testcase, 6 VMs restart every 10
>         minitues
>         >         from 11:00
>         >         > am to 16:30 pm until Dom0 crashed.
>         >         >
>         >         > Assertion 'list_empty(&vreq->next)' failed will
>         lead to
>         >         tapdisk2
>         >         > process segfault, then Dom0 crashed!
>         >         >
>         >         >
>         >         > Jun 27 16:31:05 r02k05014 kernel: device tap775.0
>         entered
>         >         promiscuous
>         >         > mode
>         >         > Jun 27 16:31:05 r02k05014 kernel: eth0: port
>         13(tap775.0)
>         >         entering
>         >         > forwarding state
>         >         > Jun 27 16:31:15 r02k05014 tapdisk2[4341]:
>         Assertion
>         >         > 'list_empty(&vreq->next)' failed, line 1822, file
>         >         tapdisk-vbd.c
>         >         > Jun 27 16:31:15 r02k05014 kernel: tapdisk2[4341]:
>         segfault
>         >         at 0 ip
>         >         > 000000000040a24f sp 00007fff0d8acb70 error 6 in
>         >         tapdisk2[400000+39000]
>         >         > Jun 28 18:58:09 r02k05014 syslogd 1.4.1: restart.
>         >         >
>         >         >
>         >         > Any one who can give me some tips?
>         >
>         >
>         >         Semi-yes. Not entirely sure about the list_empty
>         userland
>         >         crasher, but
>         >         the kernel stuff was upstreamed with some minor
>         exposed while
>         >         unmapping
>         >         pending I/O.
>         >
>         >         Which I didn't care yet to send patches for...
>         >
>         >         ... Soon, real soon now...
>         >
>         >         Daniel
>         >
>         >
>         >
>         >
>         >
>         >
>         
>         
>         
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel