]> git.itanic.dy.fi Git - linux-stable/commit
io_uring/net: ensure socket is marked connected on connect retry
authorJens Axboe <axboe@kernel.dk>
Fri, 3 Nov 2023 16:35:40 +0000 (10:35 -0600)
committerJens Axboe <axboe@kernel.dk>
Fri, 3 Nov 2023 19:25:50 +0000 (13:25 -0600)
commitf8f9ab2d98116e79d220f1d089df7464ad4e026d
treeba88cc3a5ed2a127eb2a9ecbfa3a88160f4421dd
parent0df96fb71a395b4fc9c80180306420c743f395a8
io_uring/net: ensure socket is marked connected on connect retry

io_uring does non-blocking connection attempts, which can yield some
unexpected results if a connect request is re-attempted by an an
application. This is equivalent to the following sync syscall sequence:

sock = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP);
connect(sock, &addr, sizeof(addr);

ret == -1 and errno == EINPROGRESS expected here. Now poll for POLLOUT
on sock, and when that returns, we expect the socket to be connected.
But if we follow that procedure with:

connect(sock, &addr, sizeof(addr));

you'd expect ret == -1 and errno == EISCONN here, but you actually get
ret == 0. If we attempt the connection one more time, then we get EISCON
as expected.

io_uring used to do this, but turns out that bluetooth fails with EBADFD
if you attempt to re-connect. Also looks like EISCONN _could_ occur with
this sequence.

Retain the ->in_progress logic, but work-around a potential EISCONN or
EBADFD error and only in those cases look at the sock_error(). This
should work in general and avoid the odd sequence of a repeated connect
request returning success when the socket is already connected.

This is all a side effect of the socket state being in a CONNECTING
state when we get EINPROGRESS, and only a re-connect or other related
operation will turn that into CONNECTED.

Cc: stable@vger.kernel.org
Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT")
Link: https://github.com/axboe/liburing/issues/980
Signed-off-by: Jens Axboe <axboe@kernel.dk>
io_uring/net.c