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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6DB15CDB474 for ; Mon, 23 Oct 2023 08:14:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PULgFjo3XvZz2CbSSpoedJvRALzj0yDaP0wObW5fSwg=; b=W2Ckr3J6jrfFHe Li0ONIAagvzdGETr+6j2JwT1QzMPqfIir0FBHUHEbhJDPe9H7oLRFiRYdzl5AddNLeKqPcP4UzWKG WPuFBdAkddNTxysu+n0FcguaLp1zrH+fqal/y16tR9xELVO7njWFxacar20p5xhBMW7dM4YfHhH6j JVz5hB502wVJ5WGWn9iUyCCsNZN5baGJiRgkfZ/uy+cT92/Ahv3SxojPQfj3G9ycKMIePrIRoxHi7 7EZaPQccx0q8JYub6awPakvgnotipB3AAGaR3zPGD5YTujh9z4/AbdYmfVb7nsRy2vFx6wWZtzibh x2mzhk5jEI+e7Zm83qSw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1quq4d-006iyn-2x; Mon, 23 Oct 2023 08:14:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1quq4a-006iy6-19 for linux-arm-kernel@lists.infradead.org; Mon, 23 Oct 2023 08:14:06 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4EDE82F4; Mon, 23 Oct 2023 01:14:38 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BE6B73F64C; Mon, 23 Oct 2023 01:13:56 -0700 (PDT) Date: Mon, 23 Oct 2023 09:13:54 +0100 From: Cristian Marussi To: sean yang Cc: sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] firmware: arm_scmi: Add lock for mailbox do_xfer Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231023_011404_466797_51C6B0A4 X-CRM114-Status: GOOD ( 12.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Oct 22, 2023 at 08:15:17PM +0800, sean yang wrote: > > The function do_xfer may cause multithreading send message at almost > the same time. > > send_message will write the message in the shared memory, This causes > the second write > > to overwrite the first write, resulting in the loss of the first write. > > Add lock to avoid this situation. Release lock when the message has > responded. > > Hi Xinglong , In the current SCMI stack, channels are protected from issues of concurrency at the transport layer, not here in the core, because each transport has different requirements in these regards. As an example, VirtIO SCMI transport can indeed support multiple outgoing messages in-flight if needed, so placing a global mutex here around the send_message will kill this possibility. (and in this case will serialize all because the muetx is not even per-channel but global) Each SCMI transport has its own locking placed where it is deemed needed, just look at smc or optee in send_message()/ mark_txdone(). Regarding mailboxes, which is probably the case you are referring to, the shmem_tx_prepare accessors contain some spin_until_cond() to protect the shared mem, but the core of the mutual exclusion around the channel is done really by the mailbox framework, since we register the scmi mbox client with 'knows_txdone = true' and then we use mbox_send_message() and mbox_client_txdone() to enqueue messages to the mailbox framework: in a nutshell, no message transmission will be attempted if the previous one has not completed by calling mbox_client_txdone(). I've never seen any anomalies on this. Did you notice any issue with mailboxes ? What is your setup ? Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel