In article <20050614133242.GB22812@antioche.lip6.fr>,
Manuel Bouyer  <bouyer@antioche.lip6.fr> wrote:
> On Mon, Jun 13, 2005 at 03:58:07AM +0000, Jed Davis wrote:
> > 
> > No, not really.  That is, the patch I sent has, I'm pretty sure, a
> > serious bug: if a pool allocation or xen_shm fails, xbdback_io will bail
> > out after having potentially already enqueued several IOs.  I think it
> > won't mismanage memory, but it will still defer an xbd request while
> > also performing part of it and them sending the guest a completion
> > message.  This is wrong in a number of ways.
> 
> I think we can deal with this by sending a partial xfer to the drive, it
> shouldn't break anything. But obviously the completion message has to be
> sent only one the whole request has been handled.

It looks like it's acceptable to leave requests in the Xen ring as long
as is needed, so that can be what's done for ENOMEM.

> If it's really an issue, we can preallocate the xen_shm_callback_entry in
> the xbdback_request and adjust the xen_shm interface for this. This would,
> at last, fix this issue.

Thank you; that was the idea I'd been trying to think of since, oh, Sunday.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))