problems I encountered using xen-4.1-testing and xen-unstable

problems I encountered using xen-4.1-testing and xen-unstable

[Kay, Allen M]

[-- Attachment #1.1: Type: text/plain, Size: 510 bytes --]

I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:


1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.



2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.

Has anyone seen these two problems?

Allen

[-- Attachment #1.2: Type: text/html, Size: 4540 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Konrad Rzeszutek Wilk]

On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> 
> 
> 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.

Huh. You are right. Hadn't noticed that before since I was using dom0_mem.

Ian, David: any ideas? I get the same problem and it looks as
if the area above 4GB ends up being reserved.

> 
> 
> 
> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.


That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
in blkback if you are using that version.

> 
> Has anyone seen these two problems?
> 
> Allen

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Jan Beulich]

>>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> 2.6.18 kernel in blkback if you are using that version.

Which one are you referring to?

Jan

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Konrad Rzeszutek Wilk]

On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> > with the latest upstream Linux kernel.
> > 
> > 
> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> > 2.6.18 kernel in blkback if you are using that version.
> 
> Which one are you referring to?

The fix you posted some time ago. Not all distros have picked it up.

# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;

> 
> Jan

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Jan Beulich]

>>> On 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
>> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
>> > with the latest upstream Linux kernel.
>> > 
>> > 
>> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
>> > 2.6.18 kernel in blkback if you are using that version.
>> 
>> Which one are you referring to?
> 
> The fix you posted some time ago. Not all distros have picked it up.

Ah, okay, an already fixed one - you could have said "was" instead
of "is" to not make people like me nervous...

Jan

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Konrad Rzeszutek Wilk]

On Fri, Jan 06, 2012 at 07:53:05AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> >> > with the latest upstream Linux kernel.
> >> > 
> >> > 
> >> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> >> > 2.6.18 kernel in blkback if you are using that version.
> >> 
> >> Which one are you referring to?
> > 
> > The fix you posted some time ago. Not all distros have picked it up.
> 
> Ah, okay, an already fixed one - you could have said "was" instead
> of "is" to not make people like me nervous...

Sorry - I saw it a couple of months ago with some of the cloudproviders so
it was still fresh in my mind.

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Ian Campbell]

On Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > 
> > 
> > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> 
> Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> 
> Ian, David: any ideas?

Nope. It would be nice to see some logs (xen+dom0 and native) though.

Ian.

>  I get the same problem and it looks as
> if the area above 4GB ends up being reserved.
> 
> > 
> > 
> > 
> > 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
> in blkback if you are using that version.
> 
> > 
> > Has anyone seen these two problems?
> > 
> > Allen

Re: problems I encountered using xen-4.1-testing and xen-unstable

[Konrad Rzeszutek Wilk]

On Thu, Jan 05, 2012 at 08:05:26AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > > 
> > > 
> > > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> > 
> > Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> > 
> > Ian, David: any ideas?
> 
> Nope. It would be nice to see some logs (xen+dom0 and native) though.

I tried this last night and it seems that this problem has existed in 3.0 and in 3.1 as well.
So not a regression but rather something we had never fixed. Interstingly enough you can experience
the same problem with 8GB - you end up having 6GB in dom0. Naturally you can balloon up (hadn't tried
to do it under 4GB with 2.68GB but it looks like you can certainly do it).