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 0FB72ECAAA1 for ; Thu, 15 Sep 2022 15:14:32 +0000 (UTC) Received: from localhost ([::1]:46494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYqZU-0003dZ-2c for qemu-devel@archiver.kernel.org; Thu, 15 Sep 2022 11:14:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYqYF-0002B0-3E; Thu, 15 Sep 2022 11:13:16 -0400 Received: from forwardcorp1o.mail.yandex.net ([2a02:6b8:0:1a2d::193]:38828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYqY6-0000mw-Si; Thu, 15 Sep 2022 11:13:11 -0400 Received: from myt6-81d8ab6a9f9d.qloud-c.yandex.net (myt6-81d8ab6a9f9d.qloud-c.yandex.net [IPv6:2a02:6b8:c12:520a:0:640:81d8:ab6a]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id A6C1F2E0A75; Thu, 15 Sep 2022 18:12:51 +0300 (MSK) Received: from [IPV6:2a02:6b8:b081:1208::1:d] (unknown [2a02:6b8:b081:1208::1:d]) by myt6-81d8ab6a9f9d.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id l8zbYnpCoY-CmOeng9j; Thu, 15 Sep 2022 18:12:51 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1663254771; bh=E5q1l15IxLydQYFkr5w2AYj02FPyq+78ME5X8ExPjtk=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=uMlzARHv0/TXTa8jTF/yRLSVjyPJBeW5S7CsX6lU23debzvFYhwh3Y0sVYrgDxvE8 cS8VP4gvcV2LGR3zNwECuUISu9q/bZYNQTDcG71s0OhYc+gj5Lryb3EW57iHuXeW88 FHeoiZkEZ+RX4VVnpssxZMSQxYtAIxvnqxp64mEI= Authentication-Results: myt6-81d8ab6a9f9d.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: Date: Thu, 15 Sep 2022 18:12:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v11 05/21] job.c: add job_lock/unlock while keeping job.h intact Content-Language: en-US To: Emanuele Giuseppe Esposito , qemu-block@nongnu.org Cc: Kevin Wolf , Hanna Reitz , Paolo Bonzini , John Snow , Vladimir Sementsov-Ogievskiy , Wen Congyang , Xie Changlong , Markus Armbruster , Stefan Hajnoczi , Fam Zheng , qemu-devel@nongnu.org References: <20220826132104.3678958-1-eesposit@redhat.com> <20220826132104.3678958-6-eesposit@redhat.com> From: Vladimir Sementsov-Ogievskiy In-Reply-To: <20220826132104.3678958-6-eesposit@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a02:6b8:0:1a2d::193; envelope-from=vsementsov@yandex-team.ru; helo=forwardcorp1o.mail.yandex.net X-Spam_score_int: -38 X-Spam_score: -3.9 X-Spam_bar: --- X-Spam_report: (-3.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.816, SPF_HELO_NONE=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" On 8/26/22 16:20, Emanuele Giuseppe Esposito wrote: > With "intact" we mean that all job.h functions implicitly > take the lock. Therefore API callers are unmodified. > > This means that: > - many static functions that will be always called with job lock held > become _locked, and call _locked functions > - all public functions take the lock internally if needed, and call _locked > functions > - all public functions called internally by other functions in job.c will have a > _locked counterpart (sometimes public), to avoid deadlocks (job lock already taken). > These functions are not used for now. > - some public functions called only from exernal files (not job.c) do not > have _locked() counterpart and take the lock inside. Others won't need > the lock at all because use fields only set at initialization and > never modified. > > job_{lock/unlock} is independent from real_job_{lock/unlock}. > > Note: at this stage, job_{lock/unlock} and job lock guard macros > are*nop* > > Signed-off-by: Emanuele Giuseppe Esposito > Reviewed-by: Kevin Wolf > Reviewed-by: Stefan Hajnoczi Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best regards, Vladimir