From patchwork Thu Jan 28 03:16:53 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= X-Patchwork-Id: 12051667 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF5B2C433E0 for ; Thu, 28 Jan 2021 03:17:32 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 74DA864DD0 for ; Thu, 28 Jan 2021 03:17:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74DA864DD0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.76532.138143 (Exim 4.92) (envelope-from ) id 1l4xnt-0005rk-5Y; Thu, 28 Jan 2021 03:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 76532.138143; Thu, 28 Jan 2021 03:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4xnt-0005rd-1O; Thu, 28 Jan 2021 03:17:05 +0000 Received: by outflank-mailman (input) for mailman id 76532; Thu, 28 Jan 2021 03:17:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4xnr-0005rY-T2 for xen-devel@lists.xenproject.org; Thu, 28 Jan 2021 03:17:04 +0000 Received: from wout1-smtp.messagingengine.com (unknown [64.147.123.24]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 98ee03ab-5e59-4af9-9a67-9851a0144fa8; Thu, 28 Jan 2021 03:17:01 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 92566A58; Wed, 27 Jan 2021 22:16:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 27 Jan 2021 22:16:59 -0500 Received: from localhost.localdomain (unknown [91.64.170.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 515BA24005A; Wed, 27 Jan 2021 22:16:58 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 98ee03ab-5e59-4af9-9a67-9851a0144fa8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=y0T1Vc 1V0Ig+kuARWaAkRDwv3MeY9+FY4c0Gnmg3u2Q=; b=Stny4ZHZcVWIqndMZuzKxB RbhTDIOtLDX4f2xrTXtNDpMebVNq0glArwUuYs3l0c07500tbcqsclcYJ697osJe d4XSbE4wzrbnsh9TGBERzQ6nyfc2MMDLHFMEL7SxJ1N/Y1av6VQeWwpdVpkpdsri x48F1tDSqZid4j0Xg+pv9EMmTsDw39Tjb/Df63DvN8welgs8cPZx1kP+t3R4FUVA GA0FsuGPqa5NvImROfZOIREdpKMjt3nmt1UxIoYNSvAEkpJHO82qNKKQZ9pnZXaW AzBC1FVyOH1+pBrjOkhQ+Cwc1KOi8DlBDJLCf7wIMO+drDrjKve1sXpWzJwQCmmA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofggtghogfesthekredtredtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepveektdfg tddutdetffehheejhfduhfelhefhfffgjefgfeefvddugeeghfelgfdtnecuffhomhgrih hnpehgnhhurdhorhhgnecukfhppeeluddrieegrddujedtrdekleenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: From: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Juergen Gross Subject: [PATCH] xen: Add RING_COPY_RESPONSE() Date: Thu, 28 Jan 2021 04:16:53 +0100 Message-Id: <20210128031653.1640771-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Organization: Invisible Things Lab Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly (i.e., by not considering that the other end may alter the data in the shared ring while it is being inspected). Safe usage of a response generally requires taking a local copy. Provide a RING_COPY_RESPONSE() macro to use instead of RING_GET_RESPONSE() and an open-coded memcpy(). This takes care of ensuring that the copy is done correctly regardless of any possible compiler optimizations. Use a volatile source to prevent the compiler from reordering or omitting the copy. This generalizes similar RING_COPY_REQUEST() macro added in 3f20b8def0. Signed-off-by: Marek Marczykowski-Górecki --- xen/include/public/io/ring.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h index d68615ae2f67..b63d7362f0e9 100644 --- a/xen/include/public/io/ring.h +++ b/xen/include/public/io/ring.h @@ -231,22 +231,25 @@ typedef struct __name##_back_ring __name##_back_ring_t #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) +#define RING_GET_RESPONSE(_r, _idx) \ + (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) + /* - * Get a local copy of a request. + * Get a local copy of a request/response. * - * Use this in preference to RING_GET_REQUEST() so all processing is + * Use this in preference to RING_GET_{REQUEST,RESPONSE}() so all processing is * done on a local copy that cannot be modified by the other end. * * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this * to be ineffective where _req is a struct which consists of only bitfields. */ -#define RING_COPY_REQUEST(_r, _idx, _req) do { \ +#define RING_COPY_(action, _r, _idx, _req) do { \ /* Use volatile to force the copy into _req. */ \ - *(_req) = *(volatile typeof(_req))RING_GET_REQUEST(_r, _idx); \ + *(_req) = *(volatile typeof(_req))RING_GET_##action(_r, _idx); \ } while (0) -#define RING_GET_RESPONSE(_r, _idx) \ - (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) +#define RING_COPY_REQUEST(_r, _idx, _req) RING_COPY_(REQUEST, _r, _idx, _req) +#define RING_COPY_RESPONSE(_r, _idx, _req) RING_COPY_(RESPONSE, _r, _idx, _req) /* Loop termination condition: Would the specified index overflow the ring? */ #define RING_REQUEST_CONS_OVERFLOW(_r, _cons) \