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: <Ypfvs+VsNHWQKT6H@fractal.lan>
Date:   Wed, 1 Jun 2022 16:01:07 -0700
From:   Frederik Deweerdt <frederik.deweerdt@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario

Hi Willem,

On Wed, Jun 01, 2022 at 09:24:32AM -0400, Willem de Bruijn wrote:
> 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.
> 
> >
[...]
> > @@ -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.

Thank you for the feedback, that helps!

What do you think of the attached patch?

Frederik

Signed-off-by: Frederik Deweerdt <frederik.deweerdt@...il.com>

View attachment "patch" of type "text/plain" (1156 bytes)