From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 681FA1B0439 for ; Thu, 4 Dec 2025 16:06:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764864381; cv=none; b=JFdcZH/Z9+ESiWfxd27vb+nmpXJ2Jtrx1I0EAQCwo/k+1seCUxSBGS8M35RThq1tM1ZGDiNExRjp5esz7hBJ4Mtg50YPHRpX3vYgaP++ZVKcXvDslYp50grviqUcVLyCVTz+43rmK7OdSp9VygbfR8a3Nvp6UIrSLmt8kquZXyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764864381; c=relaxed/simple; bh=xXQZL4XRqapOpPAjZe/DTlodJEzzdFw6jF/jZNBkClo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uV1bGzNP3sS4I5WmU2Z7zj6+0od19VDbynQAXLU6G9/DrrJeDlYtIdllvyMFyMz3S119xlP7m0cDn/0ZISiKPRrdkQpAD7TyiJ+5Aq66KK/asNTiwuT9J+Wvfy5Qd5VkMQ8ejNbIdawJoKgnzG4NUcu3J0G8NADItxIpB4Z44ng= 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=MJ0ef+17; arc=none smtp.client-ip=209.85.128.41 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="MJ0ef+17" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so9727175e9.3 for ; Thu, 04 Dec 2025 08:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764864378; x=1765469178; 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=dXKq9E2d1BT8u3SfgrZoGjtWQWoazLglvSADoK1+opM=; b=MJ0ef+17S9oLVDNEqv2QkrFxP/ch0Ia8d9c58eTkiWPj3v6JVtpfLRrZs04wCadrl5 bkFciE4RwulksAWdr4gXhuaLZ+umEECUUIL5LYsdrPh+KeACrY1xtvqd1ZCz/7amWU9S 2ScktO76IjzuJvW4clLErzj+06cFTLkjsMuZXrKIjaVOg3szuw1259DwcJZV4fFnbw2x FjPsdxTj1ydkyKlpB3XddRuKoaawKJm6fZP4ibMd7kpbOP578WyRu+10AoJgkjHVpwSg zZJaimJ29awPhpJ24iiSCvT1eIOEHE1NOd8PgxmHzwRzcTtF/ZZ8Tx13q0XMdGBJByV+ b4+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764864378; x=1765469178; 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=dXKq9E2d1BT8u3SfgrZoGjtWQWoazLglvSADoK1+opM=; b=mPYKFTHqEoDe7ayZx5QQ5BEIiLq8fFZSRqvGVS0ArFVfQqVO2oGUyVPXUgj633a29g g4pnq9rQb2D9BFyuPu5eaDHaiBbekSevLE/hF5Hh/f4np9IzsGRAfUIZ0grFepV5d+JF 5eb+mBbyMKumx24jo7meUza+Gn2bmBFinZPCZ6zFzRhZ4w/TZYkM7pBzTM2pm6cme0z+ TsqU0nfHpI8CDvAYnj+dwlbeT/pvl5+uIhAXc6R78sEqWwP5oATmJ1May89hX1zfQCmT ViS6CZa2y3975BE5Cwn8uQ59QWf7hq3ccMUvJe70AZ0Klr/WZkjKgcAfVTDj+z8ACIi1 mCqA== X-Forwarded-Encrypted: i=1; AJvYcCVNlUclbj9bs7du8kqUkqsnTmtKi9nylFO+UxYxNY03NOKSEE83TP9c49PH++7Ax0GJYzci757BzYDPPN4=@vger.kernel.org X-Gm-Message-State: AOJu0YxfX+eTldN11fc4ipHH2gQLJvvaQdkXOw28PEcXLDTFOPdNcj9i Xh7Ed9CjaanMHKaRtwHA/glxxeTAHadvqfMzKVGsM9yp5MKhdTxMpVha X-Gm-Gg: ASbGncvKdw1MpQFD7iR8yleYC5/U6l27gvXtDdXMGFgKKSUnw2qp909xBHNy+JvKNHm 7ziwFG86Z1WgUKj+5XBVxZtajCCBRa18xW9Ajfvq0nzhZanq0vSFU/4Nub7GIAygGK7qQgIWvGU YZlHPVMIfGZLuCnGBSQaxPCrAvXGUqAAg5DuuIc4JJK8qVunfSAHsuzgrfVLzdpas9LEpA04WTS liyS++nyc359ovyXb8PaBX9oE8VIlq5t8egj7r0JPpFX36WzWg6D4leKPgq2J3bcfWZnj728Tuf 5unWZuEww56J2I+4s3m5iw5J91lCSBBzBfIW46GRIB4q6VZ3aY+QgYd1/2Uyvb5PBgdgBZ6YicP ephaJcunTjzvAIQIflDER2zUP5K8mPAGwiNZnIlS5vxK/sIR3IT8vX3K9z4Z0OzBUpgt2XnMRJ0 zQRNnSuoeFLZJivg02Rt8AIS3Tk8sVnT1pQZ7918iN9f8+XuvszmZM X-Google-Smtp-Source: AGHT+IGjDfSaOP0WWHDkFxUHwKFzufcnMBp7gCeM0mvuDse3NTaXQKKxv3oelMPj3t4na6gRs5v1QQ== X-Received: by 2002:a05:600c:4f54:b0:477:97ca:b727 with SMTP id 5b1f17b1804b1-4792af34840mr80627185e9.19.1764864377404; Thu, 04 Dec 2025 08:06:17 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-479308cd87csm40628425e9.0.2025.12.04.08.06.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Dec 2025 08:06:16 -0800 (PST) Date: Thu, 4 Dec 2025 16:06:15 +0000 From: David Laight To: "Arnd Bergmann" Cc: "Arnd Bergmann" , "Theodore Ts'o" , "Andreas Dilger" , "Jan Kara" , "Darrick J. Wong" , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ext4: fix ext4_tune_sb_params padding Message-ID: <20251204160615.3e89de15@pumpkin> In-Reply-To: <6893f1e7-3e0b-4cf1-9c35-5d28b2507129@app.fastmail.com> References: <20251204101914.1037148-1-arnd@kernel.org> <20251204123507.2e6091a9@pumpkin> <6893f1e7-3e0b-4cf1-9c35-5d28b2507129@app.fastmail.com> 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 Thu, 04 Dec 2025 14:42:06 +0100 "Arnd Bergmann" wrote: > On Thu, Dec 4, 2025, at 13:35, David Laight wrote: > > On Thu, 4 Dec 2025 11:19:10 +0100 > > Arnd Bergmann wrote: > > > >> From: Arnd Bergmann > >> > >> The padding at the end of struct ext4_tune_sb_params is architecture > >> specific and in particular is different between x86-32 and x86-64, > >> since the __u64 member only enforces struct alignment on the latter. > > > > Is it worth adding a compile-time check for the size somewhere? > > Since the intention seems to be that any extensions will use the padding. > > There is already ABI checking with abigail that ensures that struct > members and sizes don't change in the future, which I think covers > that. I would also like to push my series to enable -Werror=padded > in the header checks, but I'm not sure yet what others think of the > idea. Putting it in the command line is going to be griefsome (at least in the short term) even for uapi headers - where you really don't want padding. (Tell that to some of the standards bodies...) It is a shame there isn't an attribute, but you can wrap definitions: #define check_padding(...) _Pragma("GCC diagnostic push"); \ _Pragma("GCC diagnostic error \"-Wpadded\""); \ __VA_ARGS__ \ _Pragma("GCC diagnostic pop"); check_padding( typedef struct fubar { int a; char b; } fred; ) /* check_padding */ I've thought about doing something similar to avoid the 'type-limits' check inside statically_true() and the like for W=1 builds. David