From patchwork Thu Feb 11 15:49:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Pinnock <1914117@bugs.launchpad.net> X-Patchwork-Id: 12083567 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AA40C433E0 for ; Thu, 11 Feb 2021 15:56:45 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 733D464D9E for ; Thu, 11 Feb 2021 15:56:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 733D464D9E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAEKh-00057O-FH for qemu-devel@archiver.kernel.org; Thu, 11 Feb 2021 10:56:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAEJk-0004f3-Ai for qemu-devel@nongnu.org; Thu, 11 Feb 2021 10:55:44 -0500 Received: from indium.canonical.com ([91.189.90.7]:36242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lAEJi-0001aH-5S for qemu-devel@nongnu.org; Thu, 11 Feb 2021 10:55:44 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1lAEJf-0007Ro-Rv for ; Thu, 11 Feb 2021 15:55:39 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id D09B12E8072 for ; Thu, 11 Feb 2021 15:55:39 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 11 Feb 2021 15:49:47 -0000 From: Chris Pinnock <1914117@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Tags: arm X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: chrispinnock th-huth X-Launchpad-Bug-Reporter: Chris Pinnock (chrispinnock) X-Launchpad-Bug-Modifier: Chris Pinnock (chrispinnock) References: <161221293549.4659.2173832767419505412.malonedeb@chaenomeles.canonical.com> Message-Id: <161305858736.3400.15732871139813179407.malone@chaenomeles.canonical.com> Subject: [Bug 1914117] Re: Short files returned via FTP on Qemu with various architectures and OSes X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="e34ce994f03aae76d4610a97bccf86c0f2cf9f70"; Instance="production" X-Launchpad-Hash: e8045c0fe4755f69d3d461233abcb9b669f56e40 Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-Spam_score_int: -65 X-Spam_score: -6.6 X-Spam_bar: ------ X-Spam_report: (-6.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1914117 <1914117@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Writeup as promised. Symptom: -------- Qemu on Mac OS X - both Catalina and Big Sur. The issue occurs in both 5.2 and 4.2* branches of Qemu. Applications such as ftp that read large amounts of data from the network may ignore valid data due to the Urgent flag being set on packets in the stream. - Install a Unix VM (e.g. NetBSD, OpenBSD, etc) on Qemu using Mac OS X. - Try to FTP a large file, such as ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz and you will be one byte short (not just this file, it's just an ex). Synopsis: --------- - On inspection, the urgent flag is being set on the last packet of data - As a result data is missing and is not received by the client app because it is considered out of band. - poll() on Mac OS X has different behaviour to other Unices. - towards the end of a stream, PRI and HUP are sent (whereas on FreeBSD and others it is not) - as a result of PRI, the slirp library used in Qemu for the user network interface adds an urgent bit to the relevant packets To see the different behaviour, we setup a server to serve a large file and wrote a client to receive it, using poll() and dumping information about the flags. Here is FreeBSD - the IN flag is set throughout. ec2-user@freebsd:~/polltest $ ./a.out -w -P lXXX.net Resolving lXXX.net: trying XXX.XXX.XXX.XXX... OK FD 3 ready: POLLIN Read 1024 byte(s) FD 3 ready: POLLIN Read 1024 total byte(s) [snipped] FD 3 ready: POLLIN Read 102400 total byte(s) ec2-user@freebsd:~/polltest $ Here is Mac OS X (Big Sur). You can see at the end of the stream, both PRI & HUP are set. Resolving lXXX.net: trying XXX.XXX.XXX.XXX .. OK FD 5 ready: POLLIN Read 1024 byte(s) [Snipped] FD 5 ready: POLLIN Read 416 byte(s) FD 5 ready: POLLIN POLLPRI POLLHUP Hangup on FD 5 Read 160 byte(s) FD 5 ready: POLLIN POLLPRI POLLHUP Hangup on FD 5 Read 102400 total byte(s) Towards a fix: -------------- The following patch removes the symptom simply by ignoring these flags. This is not necessarily the final answer, but we have run with this patch for a couple of days and haven't seen any negative behaviour. Adam Chappell figured most of this out (because a. he is (mostly) cleverer than me, b. he didn't sell his copy of Stevens UNIX Network Programming like I did in the 00s). diff -ru qemu-5.2.0/slirp/src/slirp.c qemu-5.2.0-wrk/slirp/src/slirp.c --- qemu-5.2.0/slirp/src/slirp.c 2021-02-10 11:02:07.000000000 +0000 +++ qemu-5.2.0-wrk/slirp/src/slirp.c 2021-02-10 13:07:17.000000000 +0000 @@ -23,7 +23,7 @@ * THE SOFTWARE. */ #include "slirp.h" - +#define IGNOREPOLLPRI #ifndef _WIN32 #include @@ -621,6 +621,8 @@ * This will soread as well, so no need to * test for SLIRP_POLL_IN below if this succeeds */ + +#ifndef IGNOREPOLLPRI if (revents & SLIRP_POLL_PRI) { ret = sorecvoob(so); if (ret < 0) { @@ -633,6 +635,9 @@ * Check sockets for reading */ else if (revents & +#else + if (revents & +#endif (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { /* * Check for incoming connections