Re: [Nbd] Question about the expected behaviour of nbd-server for async ops

[Alex Bligh <alex@...872...>]

Goswin,

> But since all requests are done synchronously there are no pending
> requests and closing the socket is all there is left to do. So currently
> that behaviour is as it should be.

I'm not sure what you mean by "synchronously". The current client issues
requests and processes replies asynchronously, i.e. there may be more
than one outstanding.

It happens that an exception is made for NBD_CMD_DISC, certainly
when accessed by a filing system, because prior to unmounting it
waits until the disk queues are flushed.

However, if (for instance) you do an "nbd-client -d" whilst running
a raw dd, then there might be an in-flight reply; if there's not,
its only because of synchronisation at the bio layer.

> Here is what i think should happen:
> - on recieving a NBD_CMD_DISC request you shutdown(fd, SHUT_RD)
> - process and reply any pending requests
> - fsync() /* implicit flush, just to be nice */
> - shutdown(fd, SHUT_WR)
> - close(fd)
> - exit()

That alone doesn't help (I am not sure we do the shutdown but
it might be an improvement). The issue is that there may be
replies in the tcp channel which the client has not read when
it hits close. I don't think shutdown blocks until everything
is sent, does it?

> > Right.
>
> I was thinking of a buggy or malicious client. Say there is a bug in the
> linux kernel so it sends the NBD_CMD_DISC followed by a NBD_CMD_READ.
> Then we tear down the connection and never reply to the READ. Is that
> better than replying with an error to the READ?

We tear down the client, and exit the process. The socket is closed,
so the client will get EPIPE. If the client is buggy or malicious,
that's no better than it deserves!

--
Alex Bligh