[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] netfront: rx->offset: 12, size: 4294967295


  • To: Jacek Konieczny <jajcus@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 04 Jun 2007 13:52:30 +0100
  • Delivery-date: Mon, 04 Jun 2007 05:50:44 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcempzYOdMnoBxKaEdyEowAX8io7RQ==
  • Thread-topic: [Xen-devel] netfront: rx->offset: 12, size: 4294967295



On 4/6/07 13:40, "Jacek Konieczny" <jajcus@xxxxxxxxxx> wrote:

> Ok, got it. It seems like a bug (feature?) of my compiler (gcc 4.2.0 and
> several earlier snapshots of gcc 4.2) or maybe some race condition (is
> it possible? anything else writes the netif structure?)
> 
> The problem occurs in line 377 of drivers/xen/netback/xenbus.c:
> 
>        be->netif->copying_receiver = !!rx_copy;

My suspicion is that, strictly speaking, the assignment of 1 to
copying_receiver is invalid because a single-bit bitfield can only hold the
values -1 and 0. Older gcc perhaps mapped 1 to -1, but 4.2.0 is mapping 1 to
0 (or choosing to do that as an optimisation, since it has the choice, and
hence can simplify the code to always write zero in this case). That sucks.

Can you try changing the definition of copying_receiver in netback/common.h
to be 'unsigned copying_receiver:1' instead of int:1?

 -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.