From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6BBB3B19D1 for ; Fri, 19 Jun 2026 15:12:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781881970; cv=none; b=JQA7D4aqtrpIFJBZc5xSHIbP/JD+cl9HOjeUKaDkdqqBSYCLiNrcMWM0VksRPqk6nqafkDTd4IyMd06rNrkDS9asxSyYAG468/50tzczC/FpDC9rn7ZUChqNWBrASmLAxQycVY4BgdFfCpHKYMAw5dpx1w/9ZSGpg+wjmVfHlwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781881970; c=relaxed/simple; bh=HSMSNEhNd+bx5Y4i5JFe6OOtffjEWJV7JBQ95VslDrY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZhQ1YVEZL9dUA0Og4VRalOLrhyQ+6MHxk1XUXLXmGC5BZOaHEDRw9ViGObytiBnwT9tis9KsEMRZtb09hhjZxRNXN1/5W/UQLuDtQv5g6cohrvj2NuGZHAUoR0g7dD4k2zUq+VKzX4SMcaVeCKouHG7zygmHhDxXahpNeDg2du4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=puqWMvof; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="puqWMvof" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490bb83a3f6so15001385e9.0 for ; Fri, 19 Jun 2026 08:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781881967; x=1782486767; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=dH4ItdMmE+Sfu7rO5figbb4PiJ3Ozu05hADK4M8c/ic=; b=puqWMvofG7UqTXt1Al+6HB6iRMaPvzdXr9ZJbUye9m6hFpsohmaQCUA83tQmPpJ4kJ 4z12D/Dc5q/tAYYm15IU515+xyuKmt9GcL6qfD1M1jWq8Z9J4BOyV+zhev1/zAf8u1rV GWZrHU+sqCGcvpaZLiubRhNcAHvGLATUZh/zbtoH5TnKZjX5HcfbGfeOoRxHKECZsChP hwlSXbYLCR9Qbr44xV+JCCkggJxXZ+ZAs7QvHGLJap1IGCEaTHi1yKOkY3cb/ILvpe3t PNJUI5IrEgV+GOzhTd/j2S2iNzS60uB7Ole3++xpUjuAn54xYhadnXZG73qMN91AJD3W /eQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781881967; x=1782486767; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=dH4ItdMmE+Sfu7rO5figbb4PiJ3Ozu05hADK4M8c/ic=; b=LEvFtDffrxpldGkTgj0VRi9xTMpNxnbjfXH29w248HCMXYXh8t3SXvIi5U/R0feuKs Y2WF1WqkS481AzCbpITIn1YGOYFpsPfiEfoFc007+0DSLh7iEwLIM2BBQa8H/Jg1koT0 yP3SHOXd8gCauR3/gv1Dh9Yu0a1Pv0iEKL0FMUKAbwopBk4neCBFTCehk3qev7OeqtWi uER8g9zlnJmVsYV9s+Rlk9xu67kjRm1nmhG56iLaiJiLikZWN/4GvjyLiv79SiFJMpab ZS7IrLp+A572L7QAxLn5LmzM0fQROiX/mh3N+t0KOAbTya2+dmCaNfaGcyIC7gFQNIHj Szxw== X-Forwarded-Encrypted: i=1; AFNElJ8ZwPH4zpfJcJHGG9cOMwBev0KiN1iGkvhIFGMkNbSur0C05cnrVREelB5F9zTGr3T26sL6zyjc5/X0pxk=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5Ft3mwtbe8eTd3/92Q02T8UxX/aumQh8tz1JhbqwwQaQWl2dk 7N4FtC5onLTZEZO0yBIr9JJK8nGHwqgDC1g+sUr6+nJwYQ4R7HlmLcHB X-Gm-Gg: AfdE7ckiFzdfnKT3IoMSjCSXK6kMNeaLfQNnWtyO3v9n1HJ2mP7XAoNdIshKy1B9jbe O6+ovbLl65mj39iRYMtRZeLo2gKjZPwZ6eCqyY/9Q5Y9DdHJxzJxchI8UTA1q/J5N7mGgAvFWts LWI/i6VJJrxiZ3M0Brvu1W9ZsXKBjXU8McB3q/m93RpstiKt9mGwjVdiCzv5ilZe7GbYpgh+xgf ueANR3QICyCPcBTnZIcRnPadBtHHg4AwWkFXFTp8Ta11Cn3B1sQjwQ4bCb3MzbsRRw6YJFNTOZD sxgsp906YDW3XaosO2HXEHMiL//0yVNUbNjMfqPOZkA0UnJC8x1sf6cNN4kiVjN1g760qL/BXGy IpPJh4C8QxVqjvvtYpdpMrRQgfo6WHU/Hy9N3KeVK/oHAr4fBbVJ1tx5zRhOnrqqShnPPw8LpWB AKL3iSbYruhAWsqtYStHrTOo8bHwAkrb8SxY4oI1BmODWd9IQo7g== X-Received: by 2002:a05:600c:6216:b0:48a:5565:ec3d with SMTP id 5b1f17b1804b1-4923f571e98mr69928785e9.22.1781881966994; Fri, 19 Jun 2026 08:12:46 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4650bc422c0sm8358845f8f.26.2026.06.19.08.12.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 08:12:46 -0700 (PDT) Date: Fri, 19 Jun 2026 16:12:45 +0100 From: David Laight To: Greg KH Cc: Rishi Chhibber , arnd@arndb.de, linux-kernel@vger.kernel.org, ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com, vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com, tapas.kundu@broadcom.com Subject: Re: [PATCH v2] misc: vmw_zerocopy: Add VMware zero-copy buffer sharing driver Message-ID: <20260619161245.031681e5@pumpkin> In-Reply-To: <2026061913-reattach-prowling-503a@gregkh> References: <20260617203125.397427-1-rishi.chhibber@broadcom.com> <20260618181034.1483738-1-rishi.chhibber@broadcom.com> <2026061913-reattach-prowling-503a@gregkh> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 19 Jun 2026 07:10:33 +0200 Greg KH wrote: > On Thu, Jun 18, 2026 at 11:10:34AM -0700, Rishi Chhibber wrote: > > +/* > > + * Used for sending user buffer. > > + * Either is optional but not both. > > + * > > + * Pointers are __u64 so the struct layout is identical on 32-bit and 64-bit > > + * userspace, avoiding a compat_ioctl handler. Use u64_to_user_ptr() in the > > + * driver to convert back to a __user pointer. > > + */ > > +struct vmw_zc_guest_data { > > + __u64 buffer; > > + __u32 buffer_length; > > + __u64 metadata; > > + __u32 metadata_length; > > +} __packed; > > You have an unaligned metadata pointer here in the structure, are you > sure that's a good idea? Or can you not change that anymore? The compiler is going to assume the whole thing can be misaligned. Possibly: > > +struct vmw_zc_guest_data { > > + __u64 buffer; > > + __u32 buffer_length; > > + __u64 metadata __packed; > > + __u32 metadata_length; > > +}; which just removes the pad before 'metadata' while leaving the structure itself aligned. The compiler will then only use two 32bit accesses for metadata instead of byte accesses for all the structure members. -- David