| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0
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
|
|
|
| |
|
Home