| 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
| ||
|
Date: Tue, 31 May 2022 19:47:45 -0700 From: Frederik Deweerdt <frederik.deweerdt@...il.com> To: netdev@...r.kernel.org Cc: willemb@...gle.com, Frederik Deweerdt <frederik.deweerdt@...il.com> Subject: [PATCH] [doc] msg_zerocopy.rst: clarify the TCP shutdown scenario 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. 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. Notification Batching ~~~~~~~~~~~~~~~~~~~~~ -- 2.36.1
Powered by blists - more mailing lists