In article <d8aovu$a59$1@sea.gmane.org>, Jed Davis <jdev@panix.com> wrote:
> In article <d88qle$s6r$1@sea.gmane.org>, Jed Davis <jdev@panix.com> wrote:
> > 
> > So I might even be able to fix this myself, if no-one more knowledgeable
> > is working on it.
> 
> And I think I have

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.

And the other changes I'm making don't, so far as I know, sidestep this
issue.  I think I'll have to chain the actual IOs together, toss them
if a pool_get fails, run them all at the end of the segment loop, and
adjust the xenshm callback to match.  Except that the callback can fail
to install for want of memory, it looks like.  That's... annoying.

This will be especially fun since I don't know that either NetBSD or
Linux, even given what started this thread, will ever touch the case
where one xbd request yields multiple IOs, once I'm done with this.
Unfortunately, so far as I know, such requests are still valid and need
to be handled.

-- 
(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)))))