From nobody Fri Dec 19 15:46:37 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EB96C83F14 for ; Tue, 29 Aug 2023 18:30:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238109AbjH2S3w (ORCPT ); Tue, 29 Aug 2023 14:29:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238100AbjH2S3X (ORCPT ); Tue, 29 Aug 2023 14:29:23 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0630F19A for ; Tue, 29 Aug 2023 11:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693333668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rhi2uFlmUXZCsw01PH/d6XQV/U4JpYNvRVMtZqbnhiQ=; b=cP3cOt4SJtXf4khSgp3ehlEESaOz/2fDVI5cxGhH4palpIXWYOQOx5lfpyCQO4p+41wt5C 35morEcAunhhL5cUL/2Egwtkur/AL26ehyoKtmhwPyCa0sZT1/dUWNqHAfMapreOwZ5IiQ uVzBhec4EEeZflPmzpuyyd9CqyBayfE= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-347-awnYdX2IOkqEnHT6zEosng-1; Tue, 29 Aug 2023 14:27:44 -0400 X-MC-Unique: awnYdX2IOkqEnHT6zEosng-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0037E2808B29; Tue, 29 Aug 2023 18:27:44 +0000 (UTC) Received: from localhost (unknown [10.39.192.116]) by smtp.corp.redhat.com (Postfix) with ESMTP id 794641678B; Tue, 29 Aug 2023 18:27:43 +0000 (UTC) From: Stefan Hajnoczi To: kvm@vger.kernel.org Cc: David Laight , linux-kernel@vger.kernel.org, "Tian, Kevin" , Alex Williamson , Jason Gunthorpe , Stefan Hajnoczi , Jason Gunthorpe Subject: [PATCH v2 3/3] vfio: use __aligned_u64 in struct vfio_device_ioeventfd Date: Tue, 29 Aug 2023 14:27:20 -0400 Message-ID: <20230829182720.331083-4-stefanha@redhat.com> In-Reply-To: <20230829182720.331083-1-stefanha@redhat.com> References: <20230829182720.331083-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The memory layout of struct vfio_device_ioeventfd is architecture-dependent due to a u64 field and a struct size that is not a multiple of 8 bytes: - On x86_64 the struct size is padded to a multiple of 8 bytes. - On x32 the struct size is only a multiple of 4 bytes, not 8. - Other architectures may vary. Use __aligned_u64 to make memory layout consistent. This reduces the chance that 32-bit userspace on a 64-bit kernel breakage. This patch increases the struct size on x32 but this is safe because of the struct's argsz field. The kernel may grow the struct as long as it still supports smaller argsz values from userspace (e.g. applications compiled against older kernel headers). The code that uses struct vfio_device_ioeventfd already works correctly when the struct size grows, so only the struct definition needs to be changed. Suggested-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Signed-off-by: Stefan Hajnoczi Reviewed-by: Kevin Tian --- include/uapi/linux/vfio.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 777374dd7725..032e41b56506 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -864,9 +864,10 @@ struct vfio_device_ioeventfd { #define VFIO_DEVICE_IOEVENTFD_32 (1 << 2) /* 4-byte write */ #define VFIO_DEVICE_IOEVENTFD_64 (1 << 3) /* 8-byte write */ #define VFIO_DEVICE_IOEVENTFD_SIZE_MASK (0xf) - __u64 offset; /* device fd offset of write */ - __u64 data; /* data to be written */ + __aligned_u64 offset; /* device fd offset of write */ + __aligned_u64 data; /* data to be written */ __s32 fd; /* -1 for de-assignment */ + __u32 reserved; }; =20 #define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 16) --=20 2.41.0