Re: [Xen-API] XCP 1.0-beta: md on dom0 kernel causes kernel oops

[Tomoe Sugihara <sugihara@xxxxxxxxxxxxx>]

On 12/08/2010 07:53 AM, Tomoe Sugihara wrote:
> On 12/07/2010 11:51 PM, Daniel Stodden wrote:
> > On Mon, 2010-12-06 at 07:40 -0500, Tomoe Sugihara wrote:
> > > On 12/03/2010 08:03 AM, Tomoe Sugihara wrote:
> > > > On 12/02/2010 05:50 PM, Simon Rowe wrote:
> > > > > On Wednesday 01 Dec 2010 23:03:48 Tomoe Sugihara wrote:
> > > > >
> > > > > > I tried the following two and both ended up with Oops.
> > > > > >
> > > > > > 1. just two regular HDDs --- /dev/sdc and /dev/sde or whatever.
> > > > > >
> > > > > >         Here's how I reproduced just now.Very soon after dd, kernel panics.
> > > > > >
> > > > > >          $ mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sdc
> > > > > > /dev/sde mdadm: /dev/sdc appears to be part of a raid array:
> > > > > >              level=raid1 devices=2 ctime=Mon Nov 29 15:52:53 2010
> > > > > >          mdadm: /dev/sde appears to be part of a raid array:
> > > > > >              level=raid1 devices=2 ctime=Mon Nov 29 09:34:34 2010
> > > > > >          Continue creating array? y
> > > > > >          mdadm: array /dev/md0 started.
> > > > > >          $ dd if=/dev/zero of=/dev/md0 bs=1M
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2. dm linear devices which are on top of iscsi
> > > > > >
> > > > > >        mdadm --create /dev/mirror/000008bc --auto=md --bitmap=internal
> > > > > > --metadata=0 --run --bitmap-chunk=65536 --delay=5   --level=1
> > > > > > --assume-clean --raid-devices=3 /dev/mapper/00000001-00000003
> > > > > > /dev/mapper/00000002-000002d7 /dev/mapper/00000003-0000050a
> > > > > >
> > > > > >         Interestingly, his doesn't cause kernel panic; similar stack trace
> > > > > > shows up in dmsg and mdadm stalls.
> > > > > We don't support (and therefore test) software RAID in XenServer. I'll some of
> > > > > our kernel guys if there's anything obvious.
> > > > >
> > > > >         Simon
> > > > Could you see the email that I reported the issue? Here's a link to the post:
> > > > http://www.mail-archive.com/xen-api@xxxxxxxxxxxxxxxxxxx/msg02151.html
> > > >
> > > > As I said, the issue is introduced by dom0 custom patch, which I put a link to 
> > > > the repository below,
> > > > therefor it is not there in vanilla kernel.
> > > >
> > > > http://xenbits.xen.org/XCP/linux-2.6.32.pq.hg?diff/2d68a42120cf/blktap2-ioc.diff
> > > >
> > > > I would really want it to be addressed not only for our SM backend plugin but 
> > > > also for the sake
> > > > of removing the vulnerability.
> > > Hi,
> > >
> > > We would really like this to be addressed so we can test
> > > XCP 1.0 beta with our SM backend driver.
> > >
> > > I found the author and the log for the patch that introduces the oops from the 
> > > following link.
> > > http://xenbits.xen.org/XCP/linux-2.6.32.pq.hg?annotate/2d68a42120cf/blktap2-ioc.diff
> > >
> > > I didn't get what it is for, but I hope the author may be able to help this 
> > > fixed.
> > Yeah, looks like this queue got tagged for XCP on a quite unfortunate
> > edge, indeed. The patch series has long been fixed since then, but
> > merged a little further on trunk, so I can't just offer you a
> > replacement for the -ioc diff.
>
> Thanks for following this up, Daniel.
> I'll wait for a fixed kernel.
Hi,
I'm still looking forward to a fixed kernel.

> > One could replace the entire blktap2-series, or maybe there's a bigger
> > update already in the make (?).
Any update on this? I hope someone is working on the issue.

Daniel,
Thanks for sending me a set of patches off line.
Sorry, I haven't had a chance to try, though.

Best,
Tomoe

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api