From: Dave Chinner <david@fromorbit.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Xiao Yang <yangx.jy@cn.fujitsu.com>,
ltp@lists.linux.it, linux-xfs@vger.kernel.org
Subject: Re: [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check
Date: Fri, 14 Oct 2016 06:46:13 +1100 [thread overview]
Message-ID: <20161013194613.GP23194@dastard> (raw)
In-Reply-To: <20161013141145.GA12204@rei.lan>
On Thu, Oct 13, 2016 at 04:11:45PM +0200, Cyril Hrubis wrote:
> Hi!
> > Current check doesn't work since xfsprogs v4.5.0.
> > Undefined off64_t type leads to this issue, so we
> > need to define _GNU_SOURCE to make off64_t defined.
> >
> > This has been broken by upstream xfsporgs-dev commmit
> >
> > commit cb898f157f8410a03cf5f3400baa1df9e5eecd33
> > Author: Felix Janda <felix.janda@posteo.de>
> > Date: Fri Feb 5 08:34:06 2016 +1100
> >
> > linux.h: Use off64_t instead of loff_t
>
> That kind of looks like a bug in xfs-progs, since off64_t is not exposed
> from glibc unless we enable either largefile support or define
> _GNU_SOURCE. As a matter of fact the _GNU_SOURCE enables
> _LARGEFILE64_SOURCE which then enables the typedef that exposes the
> off64_t typedef.
Which is a bug in the application build - if you are doing anything
with XFS, you need to define _LARGEFILE64_SOURCE. No ifs, buts or
maybes - it's a 64 bit filesystem with 64 bit interfaces (e.g.
ioctls) and so applications that include XFS headers to poke at XFS
filesystems need to fully support 64 bit file offsets....
> So they are depending on a type that is not defined by default but since
> the code has been part of at least three releases already we have to
> apply the workaround for it anyway.
We're only going to get stricter on this - next cycle we're removing
off64_t and replacing it with off_t, and then we'll be /explicitly/
breaking the build of any application that hasn't set up it's build
environment to define off_t as a 64 bit variable. i.e. specifying
_LARGEFILE64_SOURCE before the inclusion of XFS headers will be a
mandatory requirement - that's far better than ending up with clean
builds and subtly broken applications...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check
Date: Fri, 14 Oct 2016 06:46:13 +1100 [thread overview]
Message-ID: <20161013194613.GP23194@dastard> (raw)
In-Reply-To: <20161013141145.GA12204@rei.lan>
On Thu, Oct 13, 2016 at 04:11:45PM +0200, Cyril Hrubis wrote:
> Hi!
> > Current check doesn't work since xfsprogs v4.5.0.
> > Undefined off64_t type leads to this issue, so we
> > need to define _GNU_SOURCE to make off64_t defined.
> >
> > This has been broken by upstream xfsporgs-dev commmit
> >
> > commit cb898f157f8410a03cf5f3400baa1df9e5eecd33
> > Author: Felix Janda <felix.janda@posteo.de>
> > Date: Fri Feb 5 08:34:06 2016 +1100
> >
> > linux.h: Use off64_t instead of loff_t
>
> That kind of looks like a bug in xfs-progs, since off64_t is not exposed
> from glibc unless we enable either largefile support or define
> _GNU_SOURCE. As a matter of fact the _GNU_SOURCE enables
> _LARGEFILE64_SOURCE which then enables the typedef that exposes the
> off64_t typedef.
Which is a bug in the application build - if you are doing anything
with XFS, you need to define _LARGEFILE64_SOURCE. No ifs, buts or
maybes - it's a 64 bit filesystem with 64 bit interfaces (e.g.
ioctls) and so applications that include XFS headers to poke at XFS
filesystems need to fully support 64 bit file offsets....
> So they are depending on a type that is not defined by default but since
> the code has been part of at least three releases already we have to
> apply the workaround for it anyway.
We're only going to get stricter on this - next cycle we're removing
off64_t and replacing it with off_t, and then we'll be /explicitly/
breaking the build of any application that hasn't set up it's build
environment to define off_t as a 64 bit variable. i.e. specifying
_LARGEFILE64_SOURCE before the inclusion of XFS headers will be a
mandatory requirement - that's far better than ending up with clean
builds and subtly broken applications...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-10-13 19:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 1:52 [LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check Xiao Yang
2016-10-13 14:11 ` Cyril Hrubis
2016-10-13 14:11 ` Cyril Hrubis
2016-10-13 19:46 ` Dave Chinner [this message]
2016-10-13 19:46 ` Dave Chinner
2016-10-17 9:16 ` Cyril Hrubis
2016-10-17 9:16 ` Cyril Hrubis
2016-10-18 0:04 ` Dave Chinner
2016-10-18 0:04 ` Dave Chinner
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=20161013194613.GP23194@dastard \
--to=david@fromorbit.com \
--cc=chrubis@suse.cz \
--cc=linux-xfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=yangx.jy@cn.fujitsu.com \
/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.