On 28/01/13 15:44, Konrad Rzeszutek Wilk wrote: > 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"?
That would be fine but you may want to print the bad values, in case they're useful for tracking down bugs in frontends. > 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. Ok. 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/
