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

Re: Ping: [Xen-devel] netback data access synchronization question



On 02/02/2010 15:45, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> - netbk_gop_frag() (in the context of the rx tasklet) reads
> (for a guest-to-guest transfer) pending_tx_info[] and stores the
> respective grant reference as source of the transfer in a "local"
> variable
> - net_tx_action_dealloc() (in the context of the tx tasklet) grabs the
> same grant reference and passes it to GNTTABOP_unmap_grant_ref,
> and that hypercall completes

Only happens if it is on the dealloc_ring[] which should only happen when
that frag page's reference count falls to zero. That shouldn't happen until
after the 'rx path' has copied the bits to the destination, and then drops
the skb.

> - the guest the grant ref belongs to invalidates the grant
> - net_rx_action() passes the now stale grant reference (obtained
> in netbk_gop_frag()) to GNTTABOP_copy
> 
> Since it is the source domain (of the two guests involved) potentially
> revoking the grant before the transfer can complete, it would seem
> to me that it can that way cause errors on the receiving side.
> 
> Or can all that really only happen when the source guest misbehaves,
> in which case receive errors in the other domain are a valid expression
> of that fact (with just the ugly side effect of various warning
> messages appearing in the hypervisor log)?

We mustn't send the transmitting guest a response until we are done with the
grant ref. That would be a bug. If the transmitting guest reuses the grant
before we send a response, that is a bug in the transmitting guest (and it
is reasonable for the backend to complain about it, although maybe care is
needed regarding this being an avenue for a DoS attack on dom0 logs).

 -- 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®.