[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[Xiao Yang]

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

Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
---
 m4/ltp-xfs_quota.m4 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/m4/ltp-xfs_quota.m4 b/m4/ltp-xfs_quota.m4
index c9ee335..c23412a 100644
--- a/m4/ltp-xfs_quota.m4
+++ b/m4/ltp-xfs_quota.m4
@@ -24,6 +24,7 @@ dnl
 AC_DEFUN([LTP_CHECK_XFS_QUOTACTL],[dnl
 	AC_MSG_CHECKING([for XFS quota (xfs/xqm.h)])
 	AC_LINK_IFELSE([AC_LANG_SOURCE([
+#define _GNU_SOURCE
 #include <xfs/xqm.h>
 #include <sys/quota.h>
 int main(void) {
-- 
1.8.3.1

[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[Cyril Hrubis]

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.

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.

Patch pushed, thanks.

[CCing the XFS mailing list in case they want to do something about it]

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[Dave Chinner]

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

[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[Cyril Hrubis]

Hi!
> > 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....

Ok, so this was our fault.

Is there somewhere bit fat warning that I've missed somewhere?

> > 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...

Ending the build with clear #error or something similar sounds much
better than failing with undefined type to me.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] m4/ltp-xfs_quota.m4: fix xfs quota check

[Dave Chinner]

On Mon, Oct 17, 2016 at 11:16:14AM +0200, Cyril Hrubis wrote:
> Hi!
> > > 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....
> 
> Ok, so this was our fault.

No, not your fault - the XFS headers have never made this clear.  In
the past we've tried to hide this requirement by using
glibc-specific types and it wasn't until we changed stuff to support
C libraries other than glibc for building xfsprogs that it became
clear that we needed to be explicit about this requirement.

> Is there somewhere bit fat warning that I've missed somewhere?

This was an unintentional "first warning" that there may be bugs
lurking in 32 bit application builds. It's when the first app build
failure reports started coming that we realised there was a bigger
problem we needed to fix.  :/

> > > 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...
> 
> Ending the build with clear #error or something similar sounds much
> better than failing with undefined type to me.

Yup, that's exactly what it will do. It's part of a cleanup of
xfsprogs to simply use LFS for ensuring everything is 64 bit clean
when we build. last set of patches for this were posted here:

http://oss.sgi.com/archives/xfs/2016-08/msg00390.html

And this is the one that will break the build if off_t is not a
64 bit size:

http://oss.sgi.com/archives/xfs/2016-08/msg00402.html

I'm hoping to get this in the next xfsprogs cycle....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com