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=ahrMzt5X; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 300945A0279 for ; Thu, 14 Aug 2025 07:13:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1755148384; 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=hfF72F2EbMuWhkbVe9mFi+xWDM3PECHhIcdiw3M0l9I=; b=ahrMzt5XQKp64WJi1kUa4PqpCba0Uv5d57CITDGmQNh4PzeqySKcgfS0UEHkI5l7O/qCc4 CjQ/66qwV5THszFUgJ4lTTJYnex6USl/9A9693Q0WR/3xD3AxcrEG0hDOcGnEtJ3p+jc4S PNEI4G5aKfPhvhNAQU/kgQANfQ5Xa38= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-503-88ffixVxMMqnRcj5HAPBog-1; Thu, 14 Aug 2025 01:13:00 -0400 X-MC-Unique: 88ffixVxMMqnRcj5HAPBog-1 X-Mimecast-MFC-AGG-ID: 88ffixVxMMqnRcj5HAPBog_1755148379 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3b9d41c245fso306719f8f.0 for ; Wed, 13 Aug 2025 22:13:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755148379; x=1755753179; 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=EN4uhuZ5hN19p059xsTRWFLy1Gh9HgSAdczd/RgifDs=; b=q9ywclYwtXTwE0vyK8MN29UV30T3+FzxkJcjuRrcG9FkQuAG+6ic1Z2ntEAdMH9CeK /WyB5OuifxXTKWAEzquNhZvR0XPZ3xdbbPsRC/dpZS1yy7HBVR/CYmsHgBKVhINddSb/ XrGKLFXSU+Hsoc/0AgHJqtgWvOwwyLp1E9Iqe+3aS2w13KlZdJIerSnn0XYc8eu1kDC6 4PAIlgWjggUTLmJrKi8Ijf1LzCidnLAUKdykXeHZbFrM/S9mztsw4FVE3APuvr5auXCE WgQJprgAcEdD891/LUYRHWkdaCZMztM5E5GTBz1+XRhjXo3rocYGBLfHfWHAi7DUPEGO sgnA== X-Gm-Message-State: AOJu0Yw7hm8r4lhJT+TfuBreCA5trekNGwsZTKKWFymM5kRNRoCNRBYQ Ss+VBSBtdKj8tCZkhoaOuWDrhV2TNn77aK00O0kTs9JAaDJCrQJhgfv8berjsVhsJkfVUpFtbuo yZ1B4vhnXG/xB0pmLJ8tzpnHvhSktioktDN30kKSOBlSEgrFiGI/yvA== X-Gm-Gg: ASbGncv3us0hrcSOgucKJ5ckRS5s84ijaihrBcpJaEq7G2YKpWEwOmDlycGYQUASCK8 qvgb/f7bUq6A5coZqDtWkpYHsnjoV7DFQE9lFbvk4PEEf1z5JVxmID3py8tpSHbPOk5LQ81KNm2 //bZMqVA2b8uSBDffsrLWwf0G2hOwGdu2+W8jiFj8FrIAyNbh3rkM3k+CFyEsXZTw8l8DatWuyW /nliXw7CDCj/jmduC5GxeC9JT3Ey6/qZKRhzUK3wBP7PphrLtVSVRIrZCRNZbCSdID2ar2uD+c/ SnJ1/8NkI5gUJfSXFz5YqH++dIMefTLnwJbnsjyBxy2ODAav90ND7MtpUJawhk5GfMRx X-Received: by 2002:a05:6000:2505:b0:3b7:93c3:7d49 with SMTP id ffacd0b85a97d-3b9edf42054mr1473470f8f.39.1755148378969; Wed, 13 Aug 2025 22:12:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHaC5e5JRKci7Rq0H0f8m5pZ32bMZrRpnke/B7P9AuDSkwifqCcUucJXwpGMvqx3pbjpwEH5Q== X-Received: by 2002:a05:6000:2505:b0:3b7:93c3:7d49 with SMTP id ffacd0b85a97d-3b9edf42054mr1473448f8f.39.1755148378462; Wed, 13 Aug 2025 22:12:58 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c46ee84sm48473434f8f.57.2025.08.13.22.12.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Aug 2025 22:12:57 -0700 (PDT) Date: Thu, 14 Aug 2025 07:12:55 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] treewide: Flush pcap and log files, if used, before exiting Message-ID: <20250814071255.3dfbd733@elisabeth> In-Reply-To: References: <20250813164510.3382756-1-sbrivio@redhat.com> 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: DQ_vE0kP-v1KnxXE8NOnTapvAr6r-6OCRYcjKrLoAFQ_1755148379 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID-Hash: H57AQPYHPPODK6FXYYBTBRFDBVJOQN6V X-Message-ID-Hash: H57AQPYHPPODK6FXYYBTBRFDBVJOQN6V 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 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: =20 >=20 > I think the problems are more introduced by the previous patch > d0006fa784a7 ("treewide: use _exit() over exit()"). Oops, right. > >=20 > > 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 & (s= leep 0.3; socat -T2 OPEN:large.bin TCP:88.198.0.164:5555; ); wait; diff lar= ge.bin /tmp/large.rcv || break; done > >=20 > > ...flush files and pcap if we're using them. Ignore fsync() errors for > > the log file as we obviously can't reliably log them. > >=20 > > Signed-off-by: Stefano Brivio =20 >=20 > Hmmmmm. >=20 > 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(). > 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. --=20 Stefano