On Thursday 20 August 2009, Michael S. Tsirkin wrote: > On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote: > > On Thursday 20 August 2009, Michael S. Tsirkin wrote: > > It doesn't matter that I don't want this: allowing 1 process corrupt > another's memory is a security issue. Once you get an fd, you want to > be able to use it without worrying that a bug in another process will > crash yours. Ok, got it. Yes, that would be inacceptable. > > > If you assume losing the code for the second error condition is OK, why > > > is the first one so important? That's why I used a counter (eventfd) > > > per virtqueue, on error userspace can scan the ring and poll the socket > > > and discover what's wrong, and counter ensures we can detect that error > > > happened while we were not looking. > > > > I guess we were talking about different kinds of errors here, and I'm > > still not sure which one you are talking about. > > > Non fatal errors. E.g. translation errors probably should be > non-fatal. I can also imagine working around guest bugs in > userspace. Ah, so I guess the confusion was that I was worried about errors coming from the socket file descriptor, while you were thinking of errors from the guest side, which I did not expect to happen. The errors from the socket (or chardev, as that was the start of the argument) should still fit into the categories that I mentioned, either they can be handled by the host kernel, or they are fatal. I'll read up in your code to see how you handle asynchronous non-fatal errors from the guest. Intuitively, I'd still assume that returning the first error should be enough because it will typically mean that you cannot continue without fixing it up first, and you might get the next error immediately after that. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
