From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andreas Dilger" <adilger@dilger.ca>, "Jan Kara" <jack@suse.cz>,
"Arnd Bergmann" <arnd@kernel.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: fix ext4_tune_sb_params padding
Date: Fri, 05 Dec 2025 12:22:07 +0100 [thread overview]
Message-ID: <a1807d6f-1b47-4a30-86d8-eea56d990ed9@app.fastmail.com> (raw)
In-Reply-To: <B2AC14DC-0B9D-433A-A1B0-78D0778D0A39@dilger.ca>
On Fri, Dec 5, 2025, at 11:17, Andreas Dilger wrote:
>> On Dec 4, 2025, at 3:31 AM, Jan Kara <jack@suse.cz> wrote:
>> On Thu 04-12-25 11:19:10, Arnd Bergmann wrote:
>
> While this change isn't _wrong_ per-se, it does seem very strange to have
> a 68-byte padding at the end of the struct. You have to check the number
> of __u32 fields closely to see this,
I had the same thought but decided against that because it would be
an ABI break on all architectures. The version I posted only changes
the structure size on x86-32, csky, m68k and microblaze, as far
as I can tell.
> and I wonder if this will perpetuate
> errors in the future (e.g. adding a __u64 field after mount_opts[64]).
Indeed, I can see how that could become worse.
> IMHO, it would be more clear to either add an explicit "__u32 pad_3;"
> field after mount_opts[64], or alternately declare mount_opts[68] so it
> will consume those bytes and leave the remaining fields properly aligned.
> It isn't critical if the user tools use the last 4 bytes of mount_opts[]
> or not, so they could be changed independently at some later time.
>
> Either will ensure that new fields added in place of pad[64] will be
> properly aligned in the future.
Changing mount_opts[] to 68 bytes sounds fine to me, I'll send an
updated patch for that. I've kept the Ack from Jan, please shout
if I should drop that instead.
Arnd
next prev parent reply other threads:[~2025-12-05 11:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-04 10:19 [PATCH] ext4: fix ext4_tune_sb_params padding Arnd Bergmann
2025-12-04 10:31 ` Jan Kara
2025-12-05 10:17 ` Andreas Dilger
2025-12-05 11:22 ` Arnd Bergmann [this message]
2025-12-19 8:43 ` Geert Uytterhoeven
2025-12-04 12:35 ` David Laight
2025-12-04 13:42 ` Arnd Bergmann
2025-12-04 16:06 ` David Laight
2026-01-15 15:37 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1807d6f-1b47-4a30-86d8-eea56d990ed9@app.fastmail.com \
--to=arnd@arndb.de \
--cc=adilger@dilger.ca \
--cc=arnd@kernel.org \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.