public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Carlos Maiolino <cem@kernel.org>, xfs <linux-xfs@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] xfs: port xfs/122 to the kernel
Date: Tue, 15 Oct 2024 09:59:21 -0700	[thread overview]
Message-ID: <20241015165921.GA21853@frogsfrogsfrogs> (raw)
In-Reply-To: <Zw4xYRG5LOHuBn4H@dread.disaster.area>

On Tue, Oct 15, 2024 at 08:09:53PM +1100, Dave Chinner wrote:
> On Fri, Oct 11, 2024 at 11:24:07AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Check this with every kernel and userspace build, so we can drop the
> > nonsense in xfs/122.  Roughly drafted with:
> > 
> > sed -e 's/^offsetof/\tXFS_CHECK_OFFSET/g' \
> > 	-e 's/^sizeof/\tXFS_CHECK_STRUCT_SIZE/g' \
> > 	-e 's/ = \([0-9]*\)/,\t\t\t\1);/g' \
> > 	-e 's/xfs_sb_t/struct xfs_dsb/g' \
> > 	-e 's/),/,/g' \
> > 	-e 's/xfs_\([a-z0-9_]*\)_t,/struct xfs_\1,/g' \
> > 	< tests/xfs/122.out | sort
> > 
> > and then manual fixups.
> 
> [snip on disk structures]
> 
> I don't think we can type check all these ioctl structures,
> especially the old ones.
> 
> i.e. The old ioctl structures are not padded to 64 bit boundaries,
> nor are they constructed without internal padding holes, and this is
> why compat ioctls exist. Hence any ioctl structure that has a compat
> definition in xfs_ioctl32.h can't be size checked like this....
> 
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_error_injection,		8);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_exchange_range,		40);
> > +	XFS_CHECK_STRUCT_SIZE(xfs_exntst_t,				4);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fid,				16);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fs_eofblocks,			128);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fsid,				8);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fsop_counts,			32);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fsop_geom,			256);
> > +	XFS_CHECK_STRUCT_SIZE(struct xfs_fsop_geom_v1,			112);
> 
> e.g. xfs_fsop_geom_v1 is 108 bytes on 32 bit systems, not 112:
> 
> struct compat_xfs_fsop_geom_v1 {
>         __u32                      blocksize;            /*     0     4 */
>         __u32                      rtextsize;            /*     4     4 */
>         __u32                      agblocks;             /*     8     4 */
>         __u32                      agcount;              /*    12     4 */
>         __u32                      logblocks;            /*    16     4 */
>         __u32                      sectsize;             /*    20     4 */
>         __u32                      inodesize;            /*    24     4 */
>         __u32                      imaxpct;              /*    28     4 */
>         __u64                      datablocks;           /*    32     8 */
>         __u64                      rtblocks;             /*    40     8 */
>         __u64                      rtextents;            /*    48     8 */
>         __u64                      logstart;             /*    56     8 */
>         /* --- cacheline 1 boundary (64 bytes) --- */
>         unsigned char              uuid[16];             /*    64    16 */
>         __u32                      sunit;                /*    80     4 */
>         __u32                      swidth;               /*    84     4 */
>         __s32                      version;              /*    88     4 */
>         __u32                      flags;                /*    92     4 */
>         __u32                      logsectsize;          /*    96     4 */
>         __u32                      rtsectsize;           /*   100     4 */
>         __u32                      dirblocksize;         /*   104     4 */
> 
>         /* size: 108, cachelines: 2, members: 20 */
>         /* last cacheline: 44 bytes */
> } __attribute__((__packed__));
> 
> I'm not sure we need to size check these structures - if they change
> size, the ioctl number will change and that means all the userspace
> test code built against the system /usr/include/xfs/xfs_fs.h file
> that exercises the ioctls will stop working, right? i.e. breakage
> should be pretty obvious...

It should, though I worry about the case where we accidentally change
the size on some weird architecture, some distro ships a new release
with everything built against the broken headers, and only later does
someone notice that their old program now starts failing.

I guess the question is, do we hardcode the known sizes here, e.g.

	XFS_CHECK_IOCTL_SIZE(struct xfs_fsop_geom_v1, 108, 112);

wherein we'd assert that sizeof() == 108 || sizeof() == 112?

Or not care if things happen to the ioctls?  Part of aim of this posting
was to trick the build bots into revealing which architectures break on
the compat ioctl stuff... ;)

--D

> -Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 

  reply	other threads:[~2024-10-15 16:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11 18:24 [PATCH] xfs: port xfs/122 to the kernel Darrick J. Wong
2024-10-14  6:03 ` Christoph Hellwig
2024-10-14 15:25   ` Darrick J. Wong
2024-10-15  5:09     ` Christoph Hellwig
2024-10-15 17:08       ` Darrick J. Wong
2024-10-15  0:34 ` kernel test robot
2024-10-15  1:04 ` kernel test robot
2024-10-15  9:09 ` Dave Chinner
2024-10-15 16:59   ` Darrick J. Wong [this message]
2024-10-15 22:01     ` Dave Chinner
2024-10-16 17:32       ` Darrick J. Wong
2024-10-16  8:58 ` kernel test robot

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=20241015165921.GA21853@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.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