| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Z1x89DDTQBcFenIp@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Date: Fri, 13 Dec 2024 23:59:08 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Dave Chinner <david@...morbit.com>, linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Andrey Albershteyn <aalbersh@...nel.org>,
John Garry <john.g.garry@...cle.com>
Subject: Re: [RFC 2/3] xfs_io: Add ext4 support to show FS_IOC_FSGETXATTR
details
On Thu, Dec 12, 2024 at 01:07:58PM -0800, Darrick J. Wong wrote:
> On Fri, Dec 13, 2024 at 07:44:01AM +1100, Dave Chinner wrote:
> > On Thu, Dec 12, 2024 at 08:19:19AM -0800, Darrick J. Wong wrote:
> > > On Thu, Dec 12, 2024 at 09:33:29AM +1100, Dave Chinner wrote:
> > > > On Wed, Dec 11, 2024 at 10:17:06AM -0800, Darrick J. Wong wrote:
> > > > > On Wed, Dec 11, 2024 at 01:24:03PM +0530, Ojaswin Mujoo wrote:
> > > > > > Currently with stat we only show FS_IOC_FSGETXATTR details
> > > > > > if the filesystem is XFS. With extsize support also coming
> > > > > > to ext4 make sure to show these details when -c "stat" or "statx"
> > > > > > is used.
> > > > > >
> > > > > > No functional changes for filesystems other than ext4.
> > > > > >
> > > > > > Signed-off-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
> > > > > > ---
> > > > > > io/stat.c | 38 +++++++++++++++++++++-----------------
> > > > > > 1 file changed, 21 insertions(+), 17 deletions(-)
> > > > > >
> > > > > > diff --git a/io/stat.c b/io/stat.c
> > > > > > index 326f2822e276..d06c2186cde4 100644
> > > > > > --- a/io/stat.c
> > > > > > +++ b/io/stat.c
> > > > > > @@ -97,14 +97,14 @@ print_file_info(void)
> > > > > > file->flags & IO_TMPFILE ? _(",tmpfile") : "");
> > > > > > }
> > > > > >
> > > > > > -static void
> > > > > > -print_xfs_info(int verbose)
> > > > > > +static void print_extended_info(int verbose)
> > > > > > {
> > > > > > - struct dioattr dio;
> > > > > > - struct fsxattr fsx, fsxa;
> > > > > > + struct dioattr dio;
> > > > > > + struct fsxattr fsx, fsxa;
> > > > > > + bool is_xfs_fd = platform_test_xfs_fd(file->fd);
> > > > > >
> > > > > > - if ((xfsctl(file->name, file->fd, FS_IOC_FSGETXATTR, &fsx)) < 0 ||
> > > > > > - (xfsctl(file->name, file->fd, XFS_IOC_FSGETXATTRA, &fsxa)) < 0) {
> > > > > > + if ((ioctl(file->fd, FS_IOC_FSGETXATTR, &fsx)) < 0 ||
> > > > > > + (is_xfs_fd && (xfsctl(file->name, file->fd, XFS_IOC_FSGETXATTRA, &fsxa) < 0))) {
> > > > >
> > > > > Urgh... perhaps we should call FS_IOC_FSGETXATTR and if it returns zero
> > > > > print whatever is returned, no matter what filesystem we think is
> > > > > feeding us information?
> > > >
> > > > Yes, please. FS_IOC_FSGETXATTR has been generic functionality for
> > > > some time, we should treat it the same way for all filesystems.
> > > >
> > > > > e.g.
> > > > >
> > > > > if (ioctl(file->fd, FS_IOC_FSGETXATTR, &fsx)) < 0) {
> > > > > if (is_xfs_fd || (errno != EOPNOTSUPP &&
> > > > > errno != ENOTTY))
> > > > > perror("FS_IOC_GETXATTR");
> > > >
> > > > Why do we even need "is_xfs_fd" there? XFS will never give a
> > > > EOPNOTSUPP or ENOTTY error to this or the FS_IOC_GETXATTRA ioctl...
> > >
> > > Yeah, in hindsight I don't think it's needed for FS_IOC_FSGETXATTR, but
> >
> > *nod*
> >
> > > it's definitely nice for XFS_IOC_FSGETXATTRA (which is not implemented
> > > outside xfs) so that you don't get unnecessary error messages on ext4.
> >
> > I don't think we even need it for FS_IOC_GETXATTRA - if the
> > filesystem does not support that ioctl, we don't print the fields,
> > nor do we output an error.
> >
> > After all, this "extended info" and it's only ever been printed
> > for XFS, so we can define whatever semantics we want for foreign
> > filesystem output right now. As long as XFS always prints the same
> > info as it always has (i.e. all of it), we can do whatever we want
> > with the foreign filesystem stuff.
> >
> > Keep in mind that we don't need platform tests for XFS files - that
> > has already been done when the file was opened and the state stored
> > in file->flags via the IO_FOREIGN flag. We already use that in the
> > stat_f() to determine whether we print the "xfs info" or not.
> >
> > IOWs, I think all we need to do is move where we check the
> > IO_FOREIGN flag. i.e.:
> >
> > print_extented_info(file)
> > {
> > struct dioattr dio = {};
> > struct fsxattr fsx = {}, fsxa = {};
> >
> > if (ioctl(file->fd, FS_IOC_FSGETXATTR, &fsx)) < 0) {
> > perror("FS_IOC_GETXATTR");
> > exitcode = 1;
> > return;
> > }
> >
> > printf(_("fsxattr.xflags = 0x%x "), fsx.fsx_xflags);
> > printxattr(fsx.fsx_xflags, verbose, 0, file->name, 1, 1);
> > printf(_("fsxattr.projid = %u\n"), fsx.fsx_projid);
> > printf(_("fsxattr.extsize = %u\n"), fsx.fsx_extsize);
> > printf(_("fsxattr.cowextsize = %u\n"), fsx.fsx_cowextsize);
> > printf(_("fsxattr.nextents = %u\n"), fsx.fsx_nextents);
> >
> > /* Only XFS supports FS_IOC_FSGETXATTRA and XFS_IOC_DIOINFO */
> > if (file->flags & IO_FOREIGN)
> > return;
> >
> > if (ioctl(file->fd, FS_IOC_FSGETXATTRA, &fsxa)) < 0) {
> > perror("FS_IOC_GETXATTRA");
> > exitcode = 1;
> > return;
> > }
> > if ((xfsctl(file->name, file->fd, XFS_IOC_DIOINFO, &dio)) < 0) {
> > perror("XFS_IOC_DIOINFO");
> > exitcode = 1;
> > return;
> > }
> >
> > printf(_("fsxattr.naextents = %u\n"), fsxa.fsx_nextents);
> > printf(_("dioattr.mem = 0x%x\n"), dio.d_mem);
> > printf(_("dioattr.miniosz = %u\n"), dio.d_miniosz);
> > printf(_("dioattr.maxiosz = %u\n"), dio.d_maxiosz);
> > }
> >
> > Thoughts?
>
> Seems fine to me, though I'd print the fsxa before trying to call
> DIOINFO.
>
> --D
Got it, this makes sense to me as well. I'll do something like this in
v2. Thanks!
Regards,
ojaswin
>
> > -Dave.
> > --
> > Dave Chinner
> > david@...morbit.com
> >
Powered by blists - more mailing lists