Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

On Mon, 2010-03-08 at 18:30 -0500, Joanna Rutkowska wrote:
> On 03/09/2010 12:22 AM, Daniel Stodden wrote:
> > On Sun, 2010-03-07 at 11:12 -0500, Pasi KÃrkkÃinen wrote:
> >> On Sun, Mar 07, 2010 at 02:39:09PM +0000, Keir Fraser wrote:
> >>> On 07/03/2010 14:36, "Pasi KÃrkkÃinen" <pasik@xxxxxx> wrote:
> >>>
> >>>>> Tried a few times and no luck reproducing so far. I hope some other 
> >>>>> people
> >>>>> on the list also will give it a go, since it's so easy to try it out.
> >>>>>
> >>>>
> >>>> I'm able to reproduce this with xen/master 2.6.31.6 dom0 kernel (from
> >>>> 2010-02-20),
> >>>> but I'm not able to reproduce it with the current xen/stable 2.6.32.9.
> >>>>
> >>>> I'll try with the most recent 2.6.31.6 dom0 kernel aswell..
> >>>
> >>> Thanks Pasi!
> >>>
> >>
> >> It seems to happen with the latest xen/master 2.6.31.6 aswell!
> > 
> > Does this look to you like we're corrupting memory or on-disk storage?
> > 
> > E.g. does a
> > $ dd if=/dev/zero bs=1M | hexdump -C 
> > have the same issue?
> > 
> 
> I think there might be a chance that the above executes correctly, even
> if we have memory corruption -- this might be e.g. because the actual
> "dest" buffer here would be much smaller than the fs cache buffer used
> when we copy onto disk. And so our small dest buffer might just not be
> so likely to be hit with this presumably random corruption.
> 
> Perhaps dd'ing onto /dev/shm would be a better way to check this?

I agree that a negative doesn't mean much. I'm just poking around there
because the positive would have mattered: If we still get to see it,
we're out of the storage discussion and can focus on memory corruption.

Daniel


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