On FreeBSD I'm seeing an intermittent failure in a number of the
vconn unit tests - e.g. 186 tcp vconn - refuse connection. The test
code:
139 static void
140 test_refuse_connection(int argc OVS_UNUSED, char *argv[])
141 {
142 const char *type = argv[1];
143 int expected_error;
144 struct fake_pvconn fpv;
145 struct vconn *vconn;
146
147 expected_error = (!strcmp(type, "unix") ? EPIPE
148 : !strcmp(type, "tcp") ? ECONNRESET
149 : EPROTO);
150
151 fpv_create(type, &fpv);
152 CHECK_ERRNO(vconn_open(fpv.vconn_name, OFP10_VERSION, &vconn,
153 DSCP_DEFAULT), 0);
154 fpv_close(&fpv);
155 vconn_run(vconn);
156 CHECK_ERRNO(vconn_connect(vconn), expected_error);
157 vconn_close(vconn);
158 fpv_destroy(&fpv);
159 }
The return value of vconn_connect at line 156 is variously ECONNRESET,
EPIPE, or EAGAIN, with maybe 3/4 of my runs being successful. The EPIPE
case comes from the write() in lib/strem-fd.c:fd_send(), and from
write(2):
[EPIPE] An attempt is made to write to a socket of type
SOCK_STREAM that is not connected to a peer socket.
(It looks like Linux returns ECONNRESET for this case.)
So it looks like the tcp localhost close() takes some small time to
complete, and depending on exactly when it does a different path is
taken and the failure manifests itself in a different way.
I can try to make this deterministic by having the unit test try to wait
until the close() is complete (somehow), but it may make sense to
investigate the different code paths to ensure that failure is handled
correctly for each of them. Any thoughts?
-Ed
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
