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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 330A8C38A2A for ; Thu, 7 May 2020 20:34:30 +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 EDAFA208E4 for ; Thu, 7 May 2020 20:34:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="K3ak1Fko" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDAFA208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWnDn-00072O-DU; Thu, 07 May 2020 20:34:19 +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 1jWnDm-00072J-HI for xen-devel@lists.xenproject.org; Thu, 07 May 2020 20:34:18 +0000 X-Inumbo-ID: 1fae9406-90a2-11ea-9f78-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1fae9406-90a2-11ea-9f78-12813bfff9fa; Thu, 07 May 2020 20:34:18 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6FEFF208CA; Thu, 7 May 2020 20:34:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588883657; bh=K4kKz0E9D4cZDWNdpdaH4tEnjnTvj/V3B4vBoBgTNQ8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=K3ak1FkozC4HXibn3pcZBnK/rWHPTT7SfG65AewkbjlOhD3KQwqV4OferNh4Omfpb onv928ukxsrErWR4FmLRtYZ5fBfV9VDOgKTSu4uz3jawJs3c2g3OgYuSbveROKDpFz 4hxpJw7jcWHOJ5Rm9Iy1dUa8w4BRVgCX3MPaC4h0= Date: Thu, 7 May 2020 13:34:16 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH for-4.14 1/3] xen/arm: atomic: Allow read_atomic() to be used in more cases In-Reply-To: <0db53f23-197c-0dcc-b89f-274597ebc32d@xen.org> Message-ID: References: <20200502160700.19573-1-julien@xen.org> <20200502160700.19573-2-julien@xen.org> <0db53f23-197c-0dcc-b89f-274597ebc32d@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 7 May 2020, Julien Grall wrote: > Hi, > > On 07/05/2020 21:29, Stefano Stabellini wrote: > > > #define read_atomic(p) ({ > > > \ > > > - typeof(*p) __x; \ > > > - switch ( sizeof(*p) ) { \ > > > - case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break; \ > > > - case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break; \ > > > - case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break; \ > > > - case 8: __x = (typeof(*p))read_u64_atomic((uint64_t *)p); break; \ > > > - default: __x = 0; __bad_atomic_size(); break; \ > > > - } \ > > > - __x; \ > > > + union { typeof(*p) val; char c[0]; } x_; \ > > > + read_atomic_size(p, x_.c, sizeof(*p)); \ > > > > Wouldn't it be better to pass x_ as follows: > > > > read_atomic_size(p, &x_, sizeof(*p)); > > I am not sure to understand this. Are you suggesting to pass a pointer to the > union? Yes. Would it cause a problem that I couldn't spot?