From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fqnLFoTM; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 190565A0279 for ; Thu, 14 Aug 2025 07:24:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1755149065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U5oinc0M3Znxz1LCBuyopxz5q+BLUtH2kUNrSa3fe7Q=; b=fqnLFoTMvYkqhV3bCvAZHDdXE/me2vp/kesyFUNBWZmUDmU9gKkPb9YnWArPovGyrr1PYj 410W1slZR2Afol4t/nWPecDb66qSO7iIdja8/8cEjTUUjHZ1wB/oKDjv9Xw1T6Dhwf+Cvv TUSSXFfwyIMynzrpAru+KF6/8VQG+9o= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-542-VpfqV8UZNiWCP3npM-eG4Q-1; Thu, 14 Aug 2025 01:24:24 -0400 X-MC-Unique: VpfqV8UZNiWCP3npM-eG4Q-1 X-Mimecast-MFC-AGG-ID: VpfqV8UZNiWCP3npM-eG4Q_1755149063 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-45a1b05d8d0so2565225e9.1 for ; Wed, 13 Aug 2025 22:24:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755149063; x=1755753863; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=U5oinc0M3Znxz1LCBuyopxz5q+BLUtH2kUNrSa3fe7Q=; b=M9Y+XZHMBXo5GPYVG9obG2EKEIozH7Z24gDCKVDFlROjxOXPdKNO56WDDB88FBvDUr H8rXx/msfMkMqZ4G39OQg8ealAOGToGan5GKYyE7Yz9ZmoxKAetuBkZs7VreVQ4DBaOW U2D1igRrqq09Y4m8pMGv5r9uQxdhKg8kL3qphttj0JCH05Q8Ed7TVJt+YTUknUYZ66jH cc9pfTrtd3vrouSZqNRBq9iaT07CO7GjSy2NyIMYXS/8a/wSrCyp5V8W0VsH56iyEHAQ 1nkg7g8JmrU6jkDv8teu8R90GX2mGzTF+VJnGWABgczd7pZxvQqnxVADB0bXTg9JOT0R UEhg== X-Gm-Message-State: AOJu0Yz9js4VEHPLj2+sD4Jn2ZxmFfvavyL9Z3OYllUnFSFLWULYbp5O LebmETB9f0l4B5Y5QSPQgTYzJ6En/hoU5XRBBSZS90XH7wU2UU1TcAOXRUTCJMcsjDvuYz9MAu8 OMmlBm8cMYkvZAKRC1bg7Hzr2JFN7kmGTnzG397b57iq31xWLyWrWQA== X-Gm-Gg: ASbGnctUJlmgxRoOhD7GoJeUQEskEL8PhW/PcYTF0fyy+NjzUYwc4OQo/asecwkJQOm Ph5xPwO8UMMuZd1MjDr9P4L1WbOtqtZclwkwBV+Ki+TN3fcaUCvW84YSOhLorDffyr8kW88poy5 5tKXN+3/rcABZ5RrkFcq5Y/Eu+taQ8KO8VuyDQozFJ4OmG3+K3hFASSSGaFFVDTzyBGzjwu32RW cCawKO6Rc6gU8qhVFRLn9W5qKiBZlCryYB3KxWH77ryxk/aej0GwZ3d9HIYpeWbutascJ5ZCpqO 1gKeBpL2gPmVGIPZ/by2HlOthF3l4CPgoEs3xDbGJJ95khX2XjDMQKc0Yfzpjq8gqKZC X-Received: by 2002:a05:600c:4446:b0:459:dd16:ddde with SMTP id 5b1f17b1804b1-45a1b654a06mr8833665e9.23.1755149063051; Wed, 13 Aug 2025 22:24:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG04XlV0SQuGnVD0NKrwC4WqYrf97+mLEoq4T78eC2ogrDNhCMtVKZQRw8+o/t3I0VOFs6tsg== X-Received: by 2002:a05:600c:4446:b0:459:dd16:ddde with SMTP id 5b1f17b1804b1-45a1b654a06mr8833515e9.23.1755149062550; Wed, 13 Aug 2025 22:24:22 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45a1b7f6e36sm6933125e9.4.2025.08.13.22.24.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Aug 2025 22:24:21 -0700 (PDT) Date: Thu, 14 Aug 2025 07:24:19 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] treewide: Flush pcap and log files, if used, before exiting Message-ID: <20250814072419.643ec298@elisabeth> In-Reply-To: <20250814071255.3dfbd733@elisabeth> References: <20250813164510.3382756-1-sbrivio@redhat.com> <20250814071255.3dfbd733@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Ha7wnmTnzjPS-5a0-HiySA556Y5ypDoSR_YTTvkwDso_1755149063 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: P5BZLODE7P2N24HO74VDMQOTTRHF4A6I X-Message-ID-Hash: P5BZLODE7P2N24HO74VDMQOTTRHF4A6I X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Paul Holzinger X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 14 Aug 2025 07:12:55 +0200 Stefano Brivio wrote: > On Thu, 14 Aug 2025 14:10:20 +1000 > David Gibson wrote: > > > On Wed, Aug 13, 2025 at 06:45:05PM +0200, Stefano Brivio wrote: > > > I didn't imagine that occasionally truncated pcap and log files, as a > > > result of commit a9d63f91a59a ("passt-repair: use _exit() over > > > return"), would be such a big deal, until I tried to debug TCP issues > > > with this beauty: > > > > I think the problems are more introduced by the previous patch > > d0006fa784a7 ("treewide: use _exit() over exit()"). > > Oops, right. > > > > > > > while true; do ./pasta --trace -l /tmp/pasta.log -p /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555 OPEN:/tmp/large.rcv,trunc & (sleep 0.3; socat -T2 OPEN:large.bin TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv || break; done > > > > > > ...flush files and pcap if we're using them. Ignore fsync() errors for > > > the log file as we obviously can't reliably log them. > > > > > > Signed-off-by: Stefano Brivio > > > > Hmmmmm. > > > > I mean, yes, AFAICT this patch will address the immediate problem. > > But between this and 081df67d1fb2 ("conf: flush stdout before early > > exit") it seems more and more to me that _exit() just isn't what we > > want. Basically the assertion in d0006fa784a7 that "no exit handlers > > are needed" doesn't really seem to be true. > > It was a wrong assumption but just for a couple of cases, and mind that > exit() doesn't give you any guarantee anyway. While glibc might > guarantee those flushes, we're not just building against glibc. > > So, strictly speaking, at least for correctness, we should actually > keep those fflush() calls plus the ones I'm adding here, even with > exit(). Ah, wait, sorry, I just double checked and starting from Issue 7 of POSIX (referring to _exit() and _Exit()): Austin Group Interpretation 1003.1-2001 #031 is applied, separating these functions from the exit() function. and: The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. ...still, the rest of my reasoning applies. > > Here we're adding a new syscall to work around the problems with > > _exit(). In which case, why don't we add futex() to the syscall list > > and go back to exit(3). > > Because futex() just came up unexpectedly and Paul and myself had to > spend hours figuring that out, and there are good chances we'll get > something else like that from glibc in the future. > > On top of that, see CVE-2014-3153 and CVE-2020-14381 about futex(). > From a quick glance (and intuitively) fsync() is much simpler than that. > > > With Laurent working on multi-threading we might well want futexes > > anyhow. > > True, but then I'd still prefer to allow futex() explicitly, rather > than re-enabling exit handlers, because that's more predictable. -- Stefano