From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2D9DBCAC5A5 for ; Wed, 24 Sep 2025 12:36:11 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1v1Ohu-00057P-8P; Wed, 24 Sep 2025 08:34:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v1Ohq-00056x-G1 for qemu-devel@nongnu.org; Wed, 24 Sep 2025 08:34:47 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v1Ohm-0002xz-NY for qemu-devel@nongnu.org; Wed, 24 Sep 2025 08:34:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758717277; 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: in-reply-to:in-reply-to:references:references; bh=xSfN97EgIcx+6MgSKR5cMH6uuu/5vnntDFQsYCI//LU=; b=TGkUB4TJhO60X+J18fJvL5etAoJF4SwIPIaoNlaucWwY7fH9v1AkP/gLKI6xiz5wRqqVCU 9/hQnMcLKXyyioVSE2BDJD2aWgKgdetfS8S4OTnoRZ//2QGEs1fM9N17Flr0x/39fTZaTE sNpvECIQ8NEdaov3XP/o9JiCJPaS0mQ= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-178-lBK19IGxNkSjgvHx1MpekQ-1; Wed, 24 Sep 2025 08:34:35 -0400 X-MC-Unique: lBK19IGxNkSjgvHx1MpekQ-1 X-Mimecast-MFC-AGG-ID: lBK19IGxNkSjgvHx1MpekQ_1758717274 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E5BF519560B4; Wed, 24 Sep 2025 12:34:33 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.33]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 15D2D180044F; Wed, 24 Sep 2025 12:34:33 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 627FE21E6A27; Wed, 24 Sep 2025 14:34:30 +0200 (CEST) From: Markus Armbruster To: Daniel P. =?utf-8?Q?Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Hanna Reitz , Kevin Wolf , =?utf-8?Q?Marc-Andr?= =?utf-8?Q?=C3=A9?= Lureau , Christian Schoenebeck , Richard Henderson , Manos Pitsidianakis , Stefan Weil , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Gerd Hoffmann , Paolo Bonzini , "Dr. David Alan Gilbert" Subject: Re: [PATCH v3 08/20] log: avoid repeated prefix on incremental qemu_log calls In-Reply-To: <87h5ws5nxs.fsf@pond.sub.org> (Markus Armbruster's message of "Wed, 24 Sep 2025 09:06:55 +0200") References: <20250910180357.320297-1-berrange@redhat.com> <20250910180357.320297-9-berrange@redhat.com> <87plbh8cpx.fsf@pond.sub.org> <87h5ws5nxs.fsf@pond.sub.org> Date: Wed, 24 Sep 2025 14:34:30 +0200 Message-ID: <87ecrw112h.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Received-SPF: pass client-ip=170.10.133.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.444, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Pondering the interleave between logging and error reporting led me to an interleave between error reporting and itself. vreport() prints a single line to stderr in several parts: * Timestamp (if enabled) * Guest name (if enabled) * Program name * Location (if there is one) * Message type * Message text * Newline Stdio guarantees that each part comes out as a whole even when other threads print to the same FILE at the same time. But another thread's print output can still squeeze in between parts. Unlikely, but possible. To avoid it, we'd need to guard vreport()'s printing with flockfile() ... funlockfile(). Thoughts?