On Thu, Aug 20, 2009 at 04:31:36PM +0200, Arnd Bergmann wrote: > 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. Hmm, are you sure? Imagine a device going away while socket is bound to it. You get -ENXIO. It's not fatal in a sense that you can bind the socket to another device and go on, right? > 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 <>< Yes, but need to be careful not to lose that next error, and these errors only block one queue. I handle this by reporting them on an eventfd, per vq, which userspace can poll. -- MST -- 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
