All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>, netdev@vger.kernel.org
Cc: kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	Paolo Abeni <pabeni@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org
Subject: Re: [PATCH] net: Do not break out of sk_stream_wait_memory() with TIF_NOTIFY_SIGNAL
Date: Fri, 15 Mar 2024 17:02:05 +0000	[thread overview]
Message-ID: <7b82679f-9b69-4568-a61d-03eb1e4afc18@gmail.com> (raw)
In-Reply-To: <20240315100159.3898944-1-s.hauer@pengutronix.de>

On 3/15/24 10:01, Sascha Hauer wrote:
> It can happen that a socket sends the remaining data at close() time.
> With io_uring and KTLS it can happen that sk_stream_wait_memory() bails
> out with -512 (-ERESTARTSYS) because TIF_NOTIFY_SIGNAL is set for the
> current task. This flag has been set in io_req_normal_work_add() by
> calling task_work_add().

The entire idea of task_work is to interrupt syscalls and let io_uring
do its job, otherwise it wouldn't free resources it might be holding,
and even potentially forever block the syscall.

I'm not that sure about connect / close (are they not restartable?),
but it doesn't seem to be a good idea for sk_stream_wait_memory(),
which is the normal TCP blocking send path. I'm thinking of some kinds
of cases with a local TCP socket pair, the tx queue is full as well
and the rx queue of the other end, and io_uring has to run to receive
the data.

If interruptions are not welcome you can use different io_uring flags,
see IORING_SETUP_COOP_TASKRUN and/or IORING_SETUP_DEFER_TASKRUN.

Maybe I'm missing something, why not restart your syscall?


> This patch replaces signal_pending() with task_sigpending(), thus ignoring
> the TIF_NOTIFY_SIGNAL flag.
> 
> A discussion of this issue can be found at
> https://lore.kernel.org/20231010141932.GD3114228@pengutronix.de
> 
> Suggested-by: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>   net/core/stream.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/net/core/stream.c b/net/core/stream.c
> index 96fbcb9bbb30a..e9e17b48e0122 100644
> --- a/net/core/stream.c
> +++ b/net/core/stream.c
> @@ -67,7 +67,7 @@ int sk_stream_wait_connect(struct sock *sk, long *timeo_p)
>   			return -EPIPE;
>   		if (!*timeo_p)
>   			return -EAGAIN;
> -		if (signal_pending(tsk))
> +		if (task_sigpending(tsk))
>   			return sock_intr_errno(*timeo_p);
>   
>   		add_wait_queue(sk_sleep(sk), &wait);
> @@ -103,7 +103,7 @@ void sk_stream_wait_close(struct sock *sk, long timeout)
>   		do {
>   			if (sk_wait_event(sk, &timeout, !sk_stream_closing(sk), &wait))
>   				break;
> -		} while (!signal_pending(current) && timeout);
> +		} while (!task_sigpending(current) && timeout);
>   
>   		remove_wait_queue(sk_sleep(sk), &wait);
>   	}
> @@ -134,7 +134,7 @@ int sk_stream_wait_memory(struct sock *sk, long *timeo_p)
>   			goto do_error;
>   		if (!*timeo_p)
>   			goto do_eagain;
> -		if (signal_pending(current))
> +		if (task_sigpending(current))
>   			goto do_interrupted;
>   		sk_clear_bit(SOCKWQ_ASYNC_NOSPACE, sk);
>   		if (sk_stream_memory_free(sk) && !vm_wait)

-- 
Pavel Begunkov

  parent reply	other threads:[~2024-03-15 17:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-15 10:01 [PATCH] net: Do not break out of sk_stream_wait_memory() with TIF_NOTIFY_SIGNAL Sascha Hauer
2024-03-15 16:43 ` Jens Axboe
2024-03-15 17:02 ` Pavel Begunkov [this message]
2024-03-18 12:10   ` Sascha Hauer
2024-03-18 13:19     ` Pavel Begunkov
2024-03-19 10:50       ` Sascha Hauer
2024-03-19 13:55         ` Pavel Begunkov
2024-03-19 15:08           ` Sascha Hauer
2024-03-18 12:03 ` Sascha Hauer
2024-03-19 12:30   ` Paolo Abeni
  -- strict thread matches above, loose matches on Subject: below --
2023-10-23 12:13 Sascha Hauer
2023-10-24 13:56 ` Paolo Abeni
2023-10-26  7:03   ` Sascha Hauer
2023-10-26  8:49     ` Paolo Abeni
2023-10-27 12:04       ` Sascha Hauer
2023-11-17 10:43         ` Marc Kleine-Budde
2023-12-19 11:00           ` Steffen Trumtrar
2023-12-19 13:13             ` Paolo Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b82679f-9b69-4568-a61d-03eb1e4afc18@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.