On Mon, Jan 28, 2013 at 11:38:50AM +0000, David Vrabel wrote: > On 25/01/13 18:43, Konrad Rzeszutek Wilk wrote: > > > > Check that the ring does not have an insane amount of requests > > (more than there could fit on the ring). > [...] > > --- a/drivers/block/xen-blkback/blkback.c > > +++ b/drivers/block/xen-blkback/blkback.c > [...] > > @@ -415,8 +415,12 @@ int xen_blkif_schedule(void *arg) > > blkif->waiting_reqs = 0; > > smp_mb(); /* clear flag *before* checking for work */ > > > > - if (do_block_io_op(blkif)) > > + rc = do_block_io_op(blkif); > > + if (rc > 0) > > blkif->waiting_reqs = 1; > > + if (rc == -EACCES) > > + wait_event_interruptible(blkif->shutdown_wq, > > + kthread_should_stop()); > > So if this happens then the backend silently stops processing any > further requests? I think it should print an error and disconnect from > the front end.
I was not sure what it should print? "Frontend provided bogus ring requests. Halting ring processing"? It does eventually disconnect from the front-end as the XenBus enters the Disconnect phase. It seemed the strike the balance - so that if the frontend negotiates again the ring can start again and penalize the frontend for giving bogus data. > > David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
