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 44BC6CAC5A5 for ; Wed, 24 Sep 2025 13:31:59 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1v1PaC-000379-9x; Wed, 24 Sep 2025 09:30:56 -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 1v1PZu-00034g-JM for qemu-devel@nongnu.org; Wed, 24 Sep 2025 09:30:50 -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 1v1PZn-0003mW-BU for qemu-devel@nongnu.org; Wed, 24 Sep 2025 09:30:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758720628; h=from:from:reply-to: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=0q0AD55+4Gr4QXqPdtncsfokbi0PrLu1WfnIPLqCwpQ=; b=ggDe8G9on35hPOZwoXZw8tEH+Fckwm+CAGP+g8gCCPVdahNpcHnAnfBpAoq22zNi3WawNN MnbyKQFKbP255JwZdIayGjSBIN6QnGgbJNaVtxcZtIFzz9nsxDIFUN/ycBmiA1TUE7XdUL VplzXAHex45lbXxu7BUVpxfXq+PtixE= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-482-xJcDF44TO1Grb2PryAc_Fw-1; Wed, 24 Sep 2025 09:30:24 -0400 X-MC-Unique: xJcDF44TO1Grb2PryAc_Fw-1 X-Mimecast-MFC-AGG-ID: xJcDF44TO1Grb2PryAc_Fw_1758720623 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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 878E118002C8; Wed, 24 Sep 2025 13:30:22 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.136]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 643511800446; Wed, 24 Sep 2025 13:30:17 +0000 (UTC) Date: Wed, 24 Sep 2025 14:30:13 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Markus Armbruster Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Hanna Reitz , Kevin Wolf , =?utf-8?Q?Marc-Andr=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 Message-ID: References: <20250910180357.320297-1-berrange@redhat.com> <20250910180357.320297-9-berrange@redhat.com> <87plbh8cpx.fsf@pond.sub.org> <87h5ws5nxs.fsf@pond.sub.org> <87ecrw112h.fsf@pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ecrw112h.fsf@pond.sub.org> User-Agent: Mutt/2.2.14 (2025-02-20) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@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, T_SPF_TEMPERROR=0.01 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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, Sep 24, 2025 at 02:34:30PM +0200, Markus Armbruster wrote: > 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? You are totally correct. The qemu_log code will do the right thing with flockfile /funlockfile, but we're missing that serialization in the error report code. It doesn't matter quite as much as logging, since much of time when error_report is used, it is in a scenario that is likely to either be serialized, or be about to call exit/ abort. None the less I'm sure we can come up with real world scenarios where error report will be concurrent in QEMU that can interleave, so we should add the flockfile usage. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|