mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
To: "david@fromorbit.com" <david@fromorbit.com>
Cc: hch <hch@lst.de>, "djwong@kernel.org" <djwong@kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"cem@kernel.org" <cem@kernel.org>
Subject: Re: [PATCH] xfs: add static size checks for structures in xfs_fs.h
Date: Mon, 9 Feb 2026 06:57:43 +0000	[thread overview]
Message-ID: <b1a2d202d6ee94fb484ebdb50d8737490177c3d8.camel@wdc.com> (raw)
In-Reply-To: <aYZquyDjPqZIcKe4@dread.disaster.area>

On Sat, 2026-02-07 at 09:27 +1100, Dave Chinner wrote:
> On Fri, Feb 06, 2026 at 01:05:58PM +1000, Wilfred Mallawa wrote:
> > From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> > 
> > This patch adds static size checks for the structures in
> > libxfs/xfs_fs.h. The structures with architecture dependent size
> > for
> > fields are ommited from this patch (such as xfs_bstat which depends
> > on
> > __kernel_long_t).
> 
> There's more than that.
> 
> Different architectures will have different padding, alignment and
> holes for the same structure (e.g. 32 bit vs 64 bit) resulting in
> different sizes for the same structure across different platforms.
> 

Ah I see. As you mentioned I do see build failures from testbot for
32bit configs. Failure on the following structures (size was calculated
for 64b).

xfs_flock64
xfs_fsop_geom_v1
xfs_growfs_data_t
xfs_growfs_rt_t
xfs_inogrp

Which checks out with having different alignment requirements. i.e
xfs_growfs_data_t would be 16B for 64b and 12B for 32b.

> This is not actually a bug in the UAPI - as long as the
> architecture's userspace and the kernel are using the same structure
> layout, variations in structure size and layout between architectures
> don't matter.

The main reason for this patch was to have as many of the UAPI
structures covered by size checks such that we would catch size changes
(padding etc...) when these structs are modified.

Would omitting the above listed and keeping the rest of the new
addition be sufficient? or are there different configs that this would
cause issues for regardless?

In any case, I will split out the deletions of the duplicates and send
that patch separately as Christoph suggested.

Regards,
Wilfred


  reply	other threads:[~2026-02-09  6:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06  3:05 Wilfred Mallawa
2026-02-06  6:08 ` Christoph Hellwig
2026-02-09  7:04   ` Wilfred Mallawa
2026-02-09 14:47     ` hch
2026-02-10  5:59       ` Wilfred Mallawa
2026-02-06  9:39 ` kernel test robot
2026-02-06 11:02 ` kernel test robot
2026-02-06 18:03 ` kernel test robot
2026-02-06 22:27 ` Dave Chinner
2026-02-09  6:57   ` Wilfred Mallawa [this message]
2026-02-09 14:41   ` Christoph Hellwig

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=b1a2d202d6ee94fb484ebdb50d8737490177c3d8.camel@wdc.com \
    --to=wilfred.mallawa@wdc.com \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®