Received: by 10.223.185.116 with SMTP id b49csp5461562wrg; Tue, 27 Feb 2018 13:51:59 -0800 (PST) X-Google-Smtp-Source: AH8x225Zp5JFDx9lpcM2H1z/T8m0JPuLe8sOBcuFF4bbCPQNgAGB1uvyWxYEEqGn9opHKPixjpcz X-Received: by 10.99.95.71 with SMTP id t68mr12303501pgb.321.1519768319030; Tue, 27 Feb 2018 13:51:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519768318; cv=none; d=google.com; s=arc-20160816; b=etp8xA4agx+z+TO3OrxKiJCHILOl7ujWIZ0/XjMVUX/Uu371L8weigtOTJDQnc9P0j uqd8aMJuSYr7QFqzwcQMWqElAAp+K6qSg87ShZeN1ka836m5+pYRXXW7pIKCoMtUwm+4 it/nhgXxx6ysBxAFQWVdEqo/5fzNFWKTOgs9bXNsy8XM8aX3XkD8J1XftWQlusee1yMA qLFpNtfcFGAOC3FuqVxvN9ZRrkh0fYx8I+lHIm0wlOQoe4rHEvnjeMsWlR4LNLGyq4Zr HOE72yZqfAaPDi/y8Zp/Woa53rRbGUEQnsiRnIp8vecpcyWNaMUX5qWeFlpeoVDAb0lP 3ewA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dmarc-filter :arc-authentication-results; bh=8PciJyuspvDsggjYHu8g78OHp6KTCnb9RdXlelutEaE=; b=fpC0NU/fXO7/wBGpAyE7gtiNNo2MFQvEqVgCzoh/7FgQ9Te8pO2lMzbcLPDZyEUuII 0kxFUn/ngLBk9GYaHPkXOSUOXbfDT/4aMyeHKM0GJWjyGhwb/eammL6/ltewnUEjJZoM t2zp6yqFCcCQ72OIJ1uoLNkqu6TUtU/T6zYbOQEss5VuzN5v6JHBPg2cUp2xWrCnmo/u //6M2rj5Es7JCInZUttiiNg03FwmqO9jJRRA0b0Kk45aDBC3I8cUtYulc6RYKeemVZwP aN6JL6ciusfS/2WuMG8C44qTljkS4puImnSUY3yIuEiF7HCXbbnYd7aAp9rM2O7LDz0g 5Epw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3si69401pfi.302.2018.02.27.13.51.44; Tue, 27 Feb 2018 13:51:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751893AbeB0Vu3 (ORCPT + 99 others); Tue, 27 Feb 2018 16:50:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:44722 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbeB0Vu2 (ORCPT ); Tue, 27 Feb 2018 16:50:28 -0500 Received: from [10.135.48.227] (unknown [12.248.85.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 90E4321784; Tue, 27 Feb 2018 21:50:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90E4321784 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=sstabellini@kernel.org Date: Tue, 27 Feb 2018 13:50:27 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Boris Ostrovsky cc: Stefano Stabellini , jgross@suse.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] pvcalls-front: 64-bit align flags In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Feb 2018, Boris Ostrovsky wrote: > On 02/27/2018 04:32 PM, Stefano Stabellini wrote: > > On Tue, 27 Feb 2018, Boris Ostrovsky wrote: > >> On 02/27/2018 02:54 PM, Stefano Stabellini wrote: > >>> We are using test_and_* operations on the status and flag fields of > >>> struct sock_mapping. However, these functions require the operand to be > >>> 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > >>> > >>> Make flags 64-bit aligned by introducing an explicit padding field. > >>> > >>> Signed-off-by: Stefano Stabellini > >>> > >>> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c > >>> index ca5b773..aa07b2a 100644 > >>> --- a/drivers/xen/pvcalls-front.c > >>> +++ b/drivers/xen/pvcalls-front.c > >>> @@ -78,6 +78,7 @@ struct sock_mapping { > >>> #define PVCALLS_STATUS_BIND 1 > >>> #define PVCALLS_STATUS_LISTEN 2 > >>> uint8_t status; > >>> + uint8_t pad[7]; > >> Does this guarantee alignment (for either status or flag)? > > Yes: status is part of a struct and a union. Unions and structs have the > > alignment of their most aligned type. In this case they are 64-bit > > aligned, as some of the fields are pointers. > > > > The padding makes sure that flags is 1+7 bytes from it. > > OK. > > What about adding __attribute__((aligned(8))) to both (with a comment > explaining reasoning)? That's fine by me > > > > > >>> /* > >>> * Internal state-machine flags. > >>> * Only one accept operation can be inflight for a socket. >