linux-kernel - Re: Regressions in v3.3-rc1 introduced by "xen/granttable: Grant tables V2 implementation"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jan 2012 22:30:35 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"annie.li@...cle.com" <annie.li@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: Regressions in v3.3-rc1 introduced by "xen/granttable: Grant
 tables V2 implementation"

On Wed, 2012-01-25 at 20:46 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> > On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> > > 
> > > .. snip..
> > > > 
> > > > and with this little patch I can get it to work:
> > > 
> > > I get the domU to boot but the network stops being responsive.
> > > I see this in the Dom0:
> > 
> > Your original patch would set the version to two in the hypervisor and
> > then ignore that and continue to use v1 so that isn't surprising.
> > 
> > > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> > > 
> > > Replacing the patch with:
> > > 
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 1cd94da..b4d4eac 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> > >  	int rc;
> > >  	struct gnttab_set_version gsv;
> > >  
> > > -	gsv.version = 2;
> > > +	if (xen_hvm_domain())
> > > +		gsv.version = 1;
> > > +	else
> > > +		gsv.version = 2;
> > >  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > > -	if (rc == 0) {
> > > +	if (rc == 0 && gsv.version == 2) {
> > >  		grant_table_version = 2;
> > >  		gnttab_interface = &gnttab_v2_ops;
> > >  	} else if (grant_table_version == 2) {
> > > 
> > > Gets me back to how it worked in Linux v3.2.
> > > 
> > > But that is just a band-aid fix...
> > 
> > The real bug is presumably either that the Linux v2 code is buggy for
> > use in an HVM guest or that Xen's support for v2 in HVM guests is either
> > buggy or explicitly disabled (in which case set_version should fail for
> > version=2).
> > 
> > Is the set_version with version=1 succeeding or failing? Likewise for
> > the version=2 call?
> 
> Both return 0. But version=2 returns the error in the hypervisor:
> 
>  (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

This was with your first (buggy) patch, right?

I think this error is because your first version of the patch switched
to v2 but then ignored that and continued to use the v1 data structures
-- hence there is a disagreement between the kernel and the hypervisor
about where the flags actually are and you get errors like the above.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/