From: Nick Bowler <nbowler@draconx.ca>
To: Brian Foster <bfoster@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
linux-xfs@vger.kernel.org
Subject: Re: Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device
Date: Tue, 11 Dec 2018 15:20:23 -0500 [thread overview]
Message-ID: <CADyTPEw6DfRO_=RbmaQC2f-2QGNtXKjcmtpcuX9VaNnRXQkH6Q@mail.gmail.com> (raw)
In-Reply-To: <CADyTPExoZigFSgzrVOEsXNk=ZGRd92AWyM5Lz_z==_xEnJt5cQ@mail.gmail.com>
On 12/11/18, Nick Bowler <nbowler@draconx.ca> wrote:
> On 12/11/18, Brian Foster <bfoster@redhat.com> wrote:
>> Given that the structure size essentially changes the command value, I'm
>> kind of curious why we have this ifdeffery in the first place. That
>> aside, the patch seems reasonable to me at a glance (though some brief
>> comments around the ifdefs would be nice).
[...]
> Current code has the ifdeffery. Also since it's a syntax error to have
> multiple case labels with the same value it'd be essential to validate
> that all supported architectures architectures end up with different
> values for each XFS_IOC_xyz and the corresponding XFS_IOC_xyz_32.
Right after I write this, I realize that it's almost certainly
the case that architectures which _don't_ define BROKEN_X86_ALIGNMENT
will have matching ioctl numbers between e.g., XFS_IOC_ALLOCSP and
XFS_IOC_ALLOCSP_32. Thus the ifdeffery is essential for the above
syntactic reason.
Cheers,
Nick
next prev parent reply other threads:[~2018-12-11 20:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 4:29 Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device Nick Bowler
2018-12-10 14:33 ` Brian Foster
2018-12-10 15:39 ` Nick Bowler
2018-12-10 16:11 ` Brian Foster
2018-12-10 16:50 ` Darrick J. Wong
2018-12-10 16:55 ` Darrick J. Wong
2018-12-10 17:46 ` Brian Foster
2018-12-10 20:54 ` Nick Bowler
2018-12-10 21:41 ` Dave Chinner
2018-12-11 7:04 ` Nick Bowler
2018-12-11 12:27 ` Brian Foster
2018-12-11 20:13 ` Nick Bowler
2018-12-11 20:20 ` Nick Bowler [this message]
2018-12-12 13:09 ` Brian Foster
2018-12-13 0:21 ` Nick Bowler
2018-12-12 4:56 ` Nick Bowler
2018-12-13 3:53 ` Dave Chinner
2018-12-13 4:14 ` Nick Bowler
2018-12-13 4:49 ` Nick Bowler
2018-12-13 21:39 ` Dave Chinner
2018-12-13 21:53 ` Nick Bowler
2018-12-14 1:43 ` Dave Chinner
2018-12-14 3:35 ` Nick Bowler
2018-12-14 3:40 ` [RFC PATCH xfstests] xfs: add tests to validate ioctl structure layout Nick Bowler
2019-01-15 15:55 ` Luis Chamberlain
2018-12-13 16:30 ` Enlarging w/ xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Inappropriate ioctl for device Darrick J. Wong
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='CADyTPEw6DfRO_=RbmaQC2f-2QGNtXKjcmtpcuX9VaNnRXQkH6Q@mail.gmail.com' \
--to=nbowler@draconx.ca \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--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 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.