[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V4 04/13] hw/9pfs: File system helper process fo
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH V4 04/13] hw/9pfs: File system helper process for qemu 9p proxy FS |
Date: |
Mon, 12 Dec 2011 12:08:33 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Dec 09, 2011 at 10:12:17PM +0530, M. Mohan Kumar wrote:
> On Friday, December 09, 2011 12:01:14 AM Stefan Hajnoczi wrote:
> > On Mon, Dec 05, 2011 at 09:48:41PM +0530, M. Mohan Kumar wrote:
> > > +static int read_request(int sockfd, struct iovec *iovec, ProxyHeader
> > > *header) +{
> > > + int retval;
> > > +
> > > + /*
> > > + * read the request header.
> > > + */
> > > + iovec->iov_len = 0;
> > > + retval = socket_read(sockfd, iovec->iov_base, PROXY_HDR_SZ);
> > > + if (retval < 0) {
> > > + return retval;
> > > + }
> > > + iovec->iov_len = PROXY_HDR_SZ;
> > > + retval = proxy_unmarshal(iovec, 0, "dd", &header->type,
> > > &header->size); + if (retval < 0) {
> > > + return retval;
> > > + }
> > > + /*
> > > + * We can't process message.size > PROXY_MAX_IO_SZ, read the
> > > complete + * message from the socket and ignore it. This ensures
> > > that + * we can correctly handle the next request. We also return +
> > > * ENOBUFS as error to indicate we ran out of buffer space. + */
> > > + if (header->size > PROXY_MAX_IO_SZ) {
> > > + int count, size;
> > > + size = header->size;
> > > + while (size > 0) {
> > > + count = MIN(PROXY_MAX_IO_SZ, size);
> > > + count = socket_read(sockfd, iovec->iov_base + PROXY_HDR_SZ,
> > > count); + if (count < 0) {
> > > + return count;
> > > + }
> > > + size -= count;
> > > + }
> >
> > I'm not sure recovery attempts are worthwhile here. The client is
> > buggy, perhaps just refuse further work.
>
> But whats the issue in trying to recover in this case?
This recovery procedure is not robust because it does not always work.
In fact it only works in the case where the header->size field was
out-of-range but accurate. That's not a likely case since the QEMU-side
code that you are writing should handle this.
If the nature of the invalid request is different, either a broken or
malicious client which does not send a valid header->size then we're
stuck in this special-case recovery trying to gobble bytes and we never
log an error.
A real recovery would be something like disconnecting and
re-establishing the connection between QEMU and the helper. This would
allow us to get back to a clean state in all cases.
Stefan
[Qemu-devel] [PATCH V4 05/13] hw/9pfs: Open and create files, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 06/13] hw/9pfs: Create other filesystem objects, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 07/13] hw/9pfs: Add stat/readlink/statfs for proxy FS, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 08/13] hw/9pfs: File ownership and others, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 09/13] hw/9pfs: xattr interfaces in proxy filesystem driver, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 10/13] hw/9pfs: Proxy getversion, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 11/13] hw/9pfs: Documentation changes related to proxy fs, M. Mohan Kumar, 2011/12/05
[Qemu-devel] [PATCH V4 12/13] hw/9pfs: man page for proxy helper, M. Mohan Kumar, 2011/12/05