From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fanny Dwargee Subject: Re: Stub domain crash on Xen v4.6.1 Date: Tue, 12 Apr 2016 11:44:16 +0200 Message-ID: References: <20160412083613.GB18096@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7286606115740868025==" Return-path: In-Reply-To: <20160412083613.GB18096@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============7286606115740868025== Content-Type: multipart/alternative; boundary=001a113367742766550530468154 --001a113367742766550530468154 Content-Type: text/plain; charset=UTF-8 Wei, It works now! Many, many thanks for your invaluable time. By the way, Do you know when the patch will be included in the stable-4.6 branch? Maybe will be on time for the 4.6.2 version? IMHO is an important patch because of the added security shielding it provides (allowing the use of stub domains on some cases). Best regards, Fanny 2016-04-12 10:36 GMT+02:00 Wei Liu : > On Tue, Apr 05, 2016 at 05:17:00PM +0200, Fanny Dwargee wrote: > > (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num > bytes 512 > (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) > (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num > bytes 512 > (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) > > This reminds me of a bug that would cause error in disk: > > http://lists.xen.org/archives/html/minios-devel/2016-04/msg00000.html > > Are you able to apply the patch in that thread and test? > > For your convenience I've attached the patch. It needs to be applied to > xen.git/extras/mini-os. > > ---8<--- > From c519e3dfcdbc1edeac994dfa3918c175aae44983 Mon Sep 17 00:00:00 2001 > From: Samuel Thibault > Date: Fri, 1 Apr 2016 20:17:01 +0200 > Subject: [PATCH] Mini-OS: netfront: fix off-by-one error introduced in > 7c8f3483 > > 7c8f3483 introduced a break within a loop in netfront.c such that > cons and nr_consumed were no longer always being incremented. The > offset at cons will be processed multiple times with the break in > place. > > This commit reverts to using the "some" variable in the loop condition, > but avoids ifdefs for the non-libc case. It also renames it to dobreak > to make its usage clearer. > > Signed-off-by: Samuel Thibault > Tested-by: Sarah Newman > --- > netfront.c | 20 ++++++-------------- > 1 file changed, 6 insertions(+), 14 deletions(-) > > diff --git a/netfront.c b/netfront.c > index 0eca5b5..b8fac62 100644 > --- a/netfront.c > +++ b/netfront.c > @@ -97,19 +97,15 @@ void network_rx(struct netfront_dev *dev) > { > RING_IDX rp,cons,req_prod; > int nr_consumed, more, i, notify; > -#ifdef HAVE_LIBC > - int some; > -#endif > + int dobreak; > > nr_consumed = 0; > moretodo: > rp = dev->rx.sring->rsp_prod; > rmb(); /* Ensure we see queued responses up to 'rp'. */ > > -#ifdef HAVE_LIBC > - some = 0; > -#endif > - for (cons = dev->rx.rsp_cons; cons != rp; nr_consumed++, cons++) > + dobreak = 0; > + for (cons = dev->rx.rsp_cons; cons != rp && !dobreak; nr_consumed++, > cons++) > { > struct net_buffer* buf; > unsigned char* page; > @@ -134,8 +130,8 @@ moretodo: > len = dev->len; > memcpy(dev->data, page+rx->offset, len); > dev->rlen = len; > - some = 1; > - break; > + /* No need to receive the rest for now */ > + dobreak = 1; > } else > #endif > dev->netif_rx(page+rx->offset,rx->status); > @@ -144,11 +140,7 @@ moretodo: > dev->rx.rsp_cons=cons; > > RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more); > -#ifdef HAVE_LIBC > - if(more && !some) goto moretodo; > -#else > - if(more) goto moretodo; > -#endif > + if(more && !dobreak) goto moretodo; > > req_prod = dev->rx.req_prod_pvt; > > -- > 2.1.4 > > --001a113367742766550530468154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wei,

It works now!

=
Many, many thanks for your invaluable time.

B= y the way, Do you know when the patch will be included in the stable-4.6 br= anch? Maybe will be on time for the 4.6.2 version?

IMHO is an important patch because of the added security shielding it prov= ides (allowing the use of stub domains on some cases).

=
Best regards,

Fanny

2016-04-12 10:36 GMT+02:00 Wei Liu <= wei.liu2@citrix.com>:
On Tue, Apr 05, 201= 6 at 05:17:00PM +0200, Fanny Dwargee wrote:

(d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num byt= es 512
(XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)
(d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num byt= es 512
(XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)

This reminds me of a bug that would cause error in disk:

http://lists.xen.org/archives/h= tml/minios-devel/2016-04/msg00000.html

Are you able to apply the patch in that thread and test?

For your convenience I've attached the patch. It needs to be applied to=
xen.git/extras/mini-os.

---8<---
>>From c519e3dfcdbc1edeac994dfa3918c175aae44983 Mon Sep 17 00:00:00 2001
From: Samuel Thibault <s= amuel.thibault@ens-lyon.org>
Date: Fri, 1 Apr 2016 20:17:01 +0200
Subject: [PATCH] Mini-OS: netfront: fix off-by-one error introduced in
=C2=A07c8f3483

7c8f3483 introduced a break within a loop in netfront.c such that
cons and nr_consumed were no longer always being incremented. The
offset at cons will be processed multiple times with the break in
place.

This commit reverts to using the "some" variable in the loop cond= ition,
but avoids ifdefs for the non-libc case. It also renames it to dobreak
to make its usage clearer.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Sarah Newman <srn@prgmr.com<= /a>>
---
=C2=A0netfront.c | 20 ++++++--------------
=C2=A01 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/netfront.c b/netfront.c
index 0eca5b5..b8fac62 100644
--- a/netfront.c
+++ b/netfront.c
@@ -97,19 +97,15 @@ void network_rx(struct netfront_dev *dev)
=C2=A0{
=C2=A0 =C2=A0 =C2=A0RING_IDX rp,cons,req_prod;
=C2=A0 =C2=A0 =C2=A0int nr_consumed, more, i, notify;
-#ifdef HAVE_LIBC
-=C2=A0 =C2=A0 int some;
-#endif
+=C2=A0 =C2=A0 int dobreak;

=C2=A0 =C2=A0 =C2=A0nr_consumed =3D 0;
=C2=A0moretodo:
=C2=A0 =C2=A0 =C2=A0rp =3D dev->rx.sring->rsp_prod;
=C2=A0 =C2=A0 =C2=A0rmb(); /* Ensure we see queued responses up to 'rp&= #39;. */

-#ifdef HAVE_LIBC
-=C2=A0 =C2=A0 some =3D 0;
-#endif
-=C2=A0 =C2=A0 for (cons =3D dev->rx.rsp_cons; cons !=3D rp; nr_consumed= ++, cons++)
+=C2=A0 =C2=A0 dobreak =3D 0;
+=C2=A0 =C2=A0 for (cons =3D dev->rx.rsp_cons; cons !=3D rp && != dobreak; nr_consumed++, cons++)
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct net_buffer* buf;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned char* page;
@@ -134,8 +130,8 @@ moretodo:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 len = =3D dev->len;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 memcpy(dev->data= , page+rx->offset, len);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev->rlen =3D le= n;
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some =3D 1;
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* No need to recei= ve the rest for now */
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dobreak =3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } else
=C2=A0#endif
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dev->netif_rx(pa= ge+rx->offset,rx->status);
@@ -144,11 +140,7 @@ moretodo:
=C2=A0 =C2=A0 =C2=A0dev->rx.rsp_cons=3Dcons;

=C2=A0 =C2=A0 =C2=A0RING_FINAL_CHECK_FOR_RESPONSES(&dev->rx,more); -#ifdef HAVE_LIBC
-=C2=A0 =C2=A0 if(more && !some) goto moretodo;
-#else
-=C2=A0 =C2=A0 if(more) goto moretodo;
-#endif
+=C2=A0 =C2=A0 if(more && !dobreak) goto moretodo;

=C2=A0 =C2=A0 =C2=A0req_prod =3D dev->rx.req_prod_pvt;

--
2.1.4


--001a113367742766550530468154-- --===============7286606115740868025== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============7286606115740868025==--