netdev - Re: [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+FuTSeCC=sKJhKEnavLA7qdwbGz=MC1wqFPoJQA04mZBqebow@mail.gmail.com>
Date:   Wed, 1 Jun 2022 09:24:32 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Frederik Deweerdt <frederik.deweerdt@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario

On Tue, May 31, 2022 at 10:48 PM Frederik Deweerdt
<frederik.deweerdt@...il.com> wrote:
>
> Hi folks,
>
> Based on my understanding, retransmissions of zero copied buffers can
> happen after `close(2)`, the patch below amends the docs to suggest how
> notifications should be handled in that case.

Not just retransmissions. The first transmission similarly may be queued.

>
> Explicitly mention that applications shouldn't be calling `close(2)` on
> a TCP socket without draining the error queue.
> ---
>  Documentation/networking/msg_zerocopy.rst | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst
> index 15920db8d35d..cb44fc1f3e3e 100644
> --- a/Documentation/networking/msg_zerocopy.rst
> +++ b/Documentation/networking/msg_zerocopy.rst
> @@ -144,6 +144,10 @@ the socket. A socket that has an error queued would normally block
>  other operations until the error is read. Zerocopy notifications have
>  a zero error code, however, to not block send and recv calls.
>
> +For protocols like TCP, where retransmissions can occur after the
> +application is done with a given connection, applications should signal
> +the close to the peer via shutdown(2), and keep polling the error queue
> +until all transmissions have completed.

A socket must not be closed until all completion notifications have
been received.

Calling shutdown is an optional step. It may be sufficient to simply
delay close.