[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.0.0x allows for data corruption in Dom0
On Mon, 2010-03-08 at 18:56 -0500, Joanna Rutkowska wrote: > On 03/09/2010 12:52 AM, Daniel Stodden wrote: > > 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. > > > > If you're thinking about a potential Dom0 disk-driver problem, then I > think we can rule this out. This is because I have tried this on both > encrypted and non-encrypted filesystems, but the pattern of corruptions > was exactly the same. If the disk driver was feeding LUKS (the crypto > driver) with a wrong data, the corruptions would definitely look > differently. I'm not considering the device drivers, rather everything on top of that. Also I didn't understand the issue is present in dom0 by the time I wrote that. Still, it'd help to figure it of the corruption came in on the way up from /dev/zero or down to the disk. That dd crossing the page cache means it's still got a long way to go. For now I'm most of all glad to hear it's not in the backends, so far thanks for that :o) Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |