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+FuTSfCCiE9c8xNCBiKtSo53hfyS4Qn5y11eY-2gyEUWC3tOA@mail.gmail.com>
Date:   Wed, 1 Jun 2022 20:29:55 -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 Wed, Jun 1, 2022 at 7:03 PM Frederik Deweerdt
<frederik.deweerdt@...il.com> wrote:
>
> 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?

Please always share patches inline.

> +++ b/Documentation/networking/msg_zerocopy.rst
> @@ -144,6 +144,11 @@ 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, transmissions can occur after the application
> +has called close(2). In cases where it's undesirable to delay calling
> +close(2) until all notifications have been processed, the application
> +can use shutdown(2), and keep polling the error queue until all
> +transmissions have completed.

Sorry to nitpick, but calling close(2) is still delayed. You meant where it's
undesirable to delay closing the TCP connection?

Shutdown can be used then. But that is not unique to msg_zerocopy?
I don't feel strongly either way. Perhaps it would be helpful to describe
what makes it is undesirable to wait with calling close.

Btw, packets leaving the host after a socket is closed is not unique to
the TCP protocol, but an effect of queuing, such as in the qdisc layer.