Re: [Qemu-devel] [PATCH] iov_send_recv(): Handle zero bytes case even if OS does not
On 12.08.2012 01:24, Peter Maydell wrote: > POSIX allows sendmsg() and recvmsg() to fail EMSGSIZE if passed a zero > msg.msg_iovlen (in particular the MacOS X implementation will do this). > Handle the case where iov_send_recv() is passed a zero byte count > explicitly, to avoid accidentally depending on the OS to treat zero > msg_iovlen as a no-op. > Signed-off-by: Peter Maydell > --- > This is what was causing 'make check' to fail on MacOS X. > The other option was to declare that a zero bytecount was illegal, I guess. I don't think sending/receiving zero bytes is a good idea in the first place. Which test were failed on MacOS? Was it failing at test-iov "random I/O"? I thought I ensured that the test does not call any i/o function with zero "count" argument. Might be I was wrong, and in that case THAT place should be fixed instead. Can you provide a bit more details please? The whole thing is actually interesting: this is indeed a system- dependent corner case which should be handled in the code to make the routine consistent. But how to fix this is an open question I think. Your approach seems to be best, but we as well may print a warning there... Thank you! /mjt > iov.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/iov.c b/iov.c > index b333061..60705c7 100644 > --- a/iov.c > +++ b/iov.c > @@ -146,6 +146,13 @@ ssize_t iov_send_recv(int sockfd, struct iovec *iov, > unsigned iov_cnt, > { > ssize_t ret; > unsigned si, ei;/* start and end indexes */ > +if (bytes == 0) { > +/* Catch the do-nothing case early, as otherwise we will pass an > + * empty iovec to sendmsg/recvmsg(), and not all implementations > + * accept this. > + */ > +return 0; > +} > > /* Find the start position, skipping `offset' bytes: > * first, skip all full-sized vector elements, */
Re: [Qemu-devel] [PATCH] iov_send_recv(): Handle zero bytes case even if OS does not
On 12 August 2012 06:29, Michael Tokarev wrote: > On 12.08.2012 01:24, Peter Maydell wrote: >> POSIX allows sendmsg() and recvmsg() to fail EMSGSIZE if passed a zero >> msg.msg_iovlen (in particular the MacOS X implementation will do this). > >> Handle the case where iov_send_recv() is passed a zero byte count >> explicitly, to avoid accidentally depending on the OS to treat zero >> msg_iovlen as a no-op. > >> Signed-off-by: Peter Maydell >> --- >> This is what was causing 'make check' to fail on MacOS X. >> The other option was to declare that a zero bytecount was illegal, I guess. > > I don't think sending/receiving zero bytes is a good idea in the > first place. Which test were failed on MacOS? Was it failing at > test-iov "random I/O"? > > I thought I ensured that the test does not call any i/o function > with zero "count" argument. Might be I was wrong, and in that > case THAT place should be fixed instead. > > Can you provide a bit more details please? Sure. It fails in test-iov: #0 0x0001103a in do_send_recv (sockfd=4, iov=0x10060ffb0, iov_cnt=0, do_send=false) at iov.c:101 #1 0x00011318 in iov_send_recv (sockfd=4, iov=0x10060ffb0, iov_cnt=3, offset=0, bytes=0, do_send=) at iov.c:179 #2 0x000125c4 in test_io () at tests/test-iov.c:229 because the test does: for (i = 0; i <= sz; ++i) { for (j = i; j <= sz; ++j) { k = i; iov_memset(iov, niov, 0, 0xff, -1); do { s = g_test_rand_int_range(0, j - k + 1); r = iov_recv(sv[0], iov, niov, k, s); so on the first time round the loop i=0 so k=0 and we pass a zero bytes count to iov_recv. > The whole thing is actually interesting: this is indeed a system- > dependent corner case which should be handled in the code to make > the routine consistent. But how to fix this is an open question > I think. Your approach seems to be best, but we as well may > print a warning there... Since sendmsg()/recvmsg() do permit you to send nothing by having a non-zero length vector whose elements are all zero bytes long, making the zero length vector a no-op seemed to be the consistent approach. -- PMM
Re: [Qemu-devel] [PATCH] iov_send_recv(): Handle zero bytes case even if OS does not
On 12.08.2012 01:24, Peter Maydell wrote: > POSIX allows sendmsg() and recvmsg() to fail EMSGSIZE if passed a zero > msg.msg_iovlen (in particular the MacOS X implementation will do this). > Handle the case where iov_send_recv() is passed a zero byte count > explicitly, to avoid accidentally depending on the OS to treat zero > msg_iovlen as a no-op. > > Signed-off-by: Peter Maydell > --- > This is what was causing 'make check' to fail on MacOS X. > The other option was to declare that a zero bytecount was illegal, I guess. Acked-by: Michael Tokarev Kevin, does this fix the test-iov failure you're seeing on one of the build bots? Thank you! /mjt > iov.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/iov.c b/iov.c > index b333061..60705c7 100644 > --- a/iov.c > +++ b/iov.c > @@ -146,6 +146,13 @@ ssize_t iov_send_recv(int sockfd, struct iovec *iov, > unsigned iov_cnt, > { > ssize_t ret; > unsigned si, ei;/* start and end indexes */ > +if (bytes == 0) { > +/* Catch the do-nothing case early, as otherwise we will pass an > + * empty iovec to sendmsg/recvmsg(), and not all implementations > + * accept this. > + */ > +return 0; > +} > > /* Find the start position, skipping `offset' bytes: > * first, skip all full-sized vector elements, */
Re: [Qemu-devel] [PATCH] iov_send_recv(): Handle zero bytes case even if OS does not
Am 12.08.2012 12:32, schrieb Michael Tokarev: > On 12.08.2012 01:24, Peter Maydell wrote: >> POSIX allows sendmsg() and recvmsg() to fail EMSGSIZE if passed a zero >> msg.msg_iovlen (in particular the MacOS X implementation will do this). >> Handle the case where iov_send_recv() is passed a zero byte count >> explicitly, to avoid accidentally depending on the OS to treat zero >> msg_iovlen as a no-op. >> >> Signed-off-by: Peter Maydell >> --- >> This is what was causing 'make check' to fail on MacOS X. >> The other option was to declare that a zero bytecount was illegal, I guess. > > Acked-by: Michael Tokarev > > Kevin, does this fix the test-iov failure you're seeing on one of > the build bots? It's not on a build bot but on my test machine, but yes, this does fix it indeed. Thanks for looking into it, Peter! Kevin