Remove the error causing #include "../fs/mount.h" statement

[JanLuca]

The include seems not to be necessary and causes problems when
compiling the module not in kernel source tree.

[JanLuca]

This pull request is the same as the one in #2 but only for branch "aufs4.6"

[sfjro]

Hello JanLuca,

JanLuca:

The include seems not to be necessary and causes problems when
compiling the module not in kernel source tree.
:::

• Remove the error causing #include "../fs/mount.h" statement

It is necessary when you enable CONFIG_AUFS_BR_FUSE.

J. R. Okajima

[JanLuca]

Sorry for the response delay.

The problem is that the include causes a build error when you try to build the module out-of-kernel-tree. I am packaging the aufs4 module for Debian at the moment and I have to remove this include statement to build the code successfully. Maybe you can add a #if-statement around the code to avoid this problem.

[sfjro]

Jan Luca Naumann:

Sorry for the response delay.

The problem is that the include causes a build error when you try to build the module out-of-kernel-tree. I am packaging the aufs4 module for Debian at the moment and I have to remove this include statement to build the code successfully. Maybe you can add a #if-statement around the code to avoid this problem.

Adding #if is possible.
But I'd like to confirm the problem before adding.
How are you compiling aufs, method 1 or 2 (in README file)?
If I add one small note about the include path, is it acceptable for
you?

J. R. Okajima

[JanLuca]

I use method 2 to build the module and there is no "../fs/mount.h" that can be included in vfsub.c.

[sfjro]

Jan Luca Naumann:

I use method 2 to build the module and there is no "../fs/mount.h" that can be included in vfsub.c.

So you didn't specify nor change KDIR make variable, right?
Then KDIR must be "/lib/modules/$(shell uname -r)/build" as described in
Makefile. Does your system have "source" dir or symlink under the same
"/lib/modules/$(shell uname -r)" too?
If I add something like
EXTRA_CFLAGS += -DKSOURCE=/lib/modules/$(shell uname -r)/source
and modify the include line like
#include KSOURCE ## "fs/mount.h"
then your compilation succeeds?

J. R. Okajima

[JanLuca]

I use DKMS to build the module. I do not change KDIR and the modules builds without problems if I remove the include. DKMS has a variable "$kernel_source_dir" that could be passed to the Makefile as e.g. KDIR, anyway.

If you can add a way so the include can be found, even if the module is built out-of-tree, this would be nice :-)

[JanLuca]

Btw, you can find the DKMS file I use for building here: https://github.com/JanLuca/aufs4-debian/blob/master/debian/aufs4-dkms.dkms

[sfjro]

Jan Luca Naumann:

Btw, you can find the DKMS file I use for building here: https://github.com/JanLuca/aufs4-debian/blob/master/debian/aufs4-dkms.dkms

Then I'd ask again.
Do you have "${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/source" dir
or symlink on your system?

J. R. Okajima

[JanLuca]

I have "/lib/modules/$(shell uname -r)/source" as kernel source dir on my machine. The KDIR variable in the Makefile is OK as it is.

[sfjro]

Jan Luca Naumann:

I have "/lib/modules/$(shell uname -r)/source" as kernel source dir on my machine. The KDIR variable in the Makefile is OK as it is.

I am confused now.
I've tried aufs4-standalone.git#aufs4.3, and succeeded.
Building with V=1, linux build system prints verbose commands. While I
don't know how your DKMS handles Makefiles, here is the output on my
test system from the ordinary make command.

~$ mkdir /tmp/w
$ cd /tmp/w
/tmp/w$ git clonem -q git://github.com/sfjro/aufs4-standalone.git .
/tmp/w#master$ git co aufs4.3
/tmp/w#aufs4.3$ uname -a
Linux jrofr 3.18.0aufsD+ #418 SMP PREEMPT Wed Aug 24 16:13:38 JST 2016 x86_64 GNU/Linux
/tmp/w#aufs4.3$ make V=1 KDIR=/aufs/aufs4-linux/D aufs.ko
:::
make -C ~/aufs/aufs4-linux/D M=/tmp/w/fs/aufs EXTRA_CFLAGS= ...
make[1]: Entering directory '/home/jro/aufs/aufs4-linux/D'
make -C /proj/aufs/aufs4-linux.git O=/home/jro/aufs/aufs4-linux/D/. modules
make -C /home/jro/aufs/aufs4-linux/D KBUILD_SRC=/proj/aufs/aufs4-linux.git
-f /proj/aufs/aufs4-linux.git/Makefile modules
:::
make -f /proj/aufs/aufs4-linux.git/scripts/Makefile.build obj=/tmp/w/fs/aufs
:::
gcc -Wp,-MD,/tmp/w/fs/aufs/.vfsub.o.d ..."various include paths"... /tmp/w/fs/aufs/vfsub.c

Notice these points.

• the running system is linux-v3.18
• building aufs4-standalone.git#aufs4.3
• v4.3 kernel source files are under /proj/aufs/aufs4-linux.git
• v4.3 kernel build dir is ~/aufs/aufs4-linux-D, which I spedified as
  KDIR
• aufs Makefile and the kernel Makefiles invoke the nested make command
• those Makefiles add the include paths.

Finally fs/aufs/vfsub.c is compiled successfully.
On my system, -I/proj/aufs/aufs4-linux.git/include is added, and
#include "../fs/mount.h" is interpreted as
/proj/aufs/aufs4-linux.git/include/../fs/mount.h which exists.

I'd suggest you to try "make" instead of "dkms" and see the difference
of the added include paths.

J. R. Okajima

[JanLuca]

So I had some time today to debug the problem a little bit more in detail:

The problem is that the header file "fs/mount.h" seems not to be part of the (public) header file generated by the kernel Makefile (only linux/mount.h is exported). Thus it is not included in e.g. the header package of Debian which is used to build e.g. DKMS modules. How important is it to include the header file?

(For completeness the gcc-line when the compilation failed:

gcc-5 -Wp,-MD,/var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs/.vfsub.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/5/include -I/usr/src/linux-headers-4.7.0-1-common/arch/x86/include -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated -I/usr/src/linux-headers-4.7.0-1-common/include -Iinclude -I/usr/src/linux-headers-4.7.0-1-common/arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I/usr/src/linux-headers-4.7.0-1-common/include/uapi -Iinclude/generated/uapi -include /usr/src/linux-headers-4.7.0-1-common/include/linux/kconfig.h -I/var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -fno-var-tracking-assignments -g -pg -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO -DFUSE_SUPER_MAGIC=0x65735546 -DXFS_SB_MAGIC=0x58465342 -DCONFIGFS_MAGIC=0x62656570 -DUBIFS_SUPER_MAGIC=0x24051905 -DHFSPLUS_SUPER_MAGIC=0x482b -DDEBUG -include /var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs/../../include/uapi/linux/aufs_type.h -I/var/lib/dkms/aufs4/4.7+20160822/build/include -DCONFIG_AUFS_FS_MODULE -UCONFIG_AUFS -DCONFIG_AUFS_BRANCH_MAX_127 -DCONFIG_AUFS_SBILIST -DCONFIG_AUFS_DEBUG -DMODULE -DKBUILD_BASENAME='"vfsub"' -DKBUILD_MODNAME='"aufs"' -c -o /var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs/.tmp_vfsub.o /var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs/vfsub.c

/var/lib/dkms/aufs4/4.7+20160822/build/fs/aufs/vfsub.c:26:25: fatal error: ../fs/mount.h: No such file or directory

)

[sfjro]

Jan Luca Naumann:

So I had some time today to debug the problem a little bit more in detail:

The problem is that the header file "fs/mount.h" seems not to be part of th=
e (public) header file generated by the kernel Makefile (only linux/mount.h=
is exported). Thus it is not included in e.g. the header package of Debian=
which is used to build e.g. DKMS modules. How important is it to include t=
he header file?

Without fs/mount.h, some features won't be compiled such as exporting
via NFS and FUSE branch. How important? It is totally depending upon
users configuration.
For your case, it might be a solution to move the #inlucde line into
#ifdef CONFIG_AUFS_BR_FUSE region in fs/aufs/vfsub.c. But, if, only if,
someday you enable CONFIG_AUFS_EXPORT, you will meet the exact same
problem again. I don't think it a good idea.

I understand that your build system DKMS (which I have never tried)
doesn't refer to the kernel source files. Instead, it gives you a
prepared (public) header files. As aufs README file says, the kernel
source tree is essentially necessary to build aufs.
How about adding
EXTRA_CFLAGS="-I/your/aufs4-standalone.git/include -I/your/kernel/source/tree/include"
into your
MAKE[0]="make -C ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build aufs.ko";
line?

J. R. Okajima

[sfjro]

------- Blind-Carbon-Copy

From: sfjro@users.sourceforge.net
Subject: Re: [Filesystems-devel] Bug#843846: aufs for 4.8: "../fs/mount.h not found" when enabling NFS export
To: Philipp Marek philipp.marek@linbit.com
Cc: Jan Luca Naumann j.naumann@fu-berlin.de, 843846@bugs.debian.org
In-Reply-To: 20161110135240.osvpazz34u3ahnon@cacao.linbit
References: 20161110082627.xewfc2sr3x4p4b5s@cacao.linbit 1320BA39-FA66-4C22-AF22-9A789F270665@fu-berlin.de 20161110085649.jzios36sh3pntgh4@cacao.linbit 3B61DDA1-C07A-4411-A41A-4A3C0209544F@fu-berlin.de 20161110135240.osvpazz34u3ahnon@cacao.linbit
Date: Tue, 22 Nov 2016 01:00:30 +0900
Message-ID: 31029.1479744030@jrobl

Philipp Marek:

But fs/mount.h does

#include <linux/mount.h>

and it seems that the linux/mount.h contains everything that AUFS needs.

I've got the module up and running for a few hours, mounting/unmounting
directories all the time (in a testsuite)... so it looks as if it's not
completely broken ;)

Sorry for the long delay.
This "aufs is compiled and working" news surprised me, and I digged down
the git log to find out why fs/mount.h is necessary.
And here is the fix which will be included in next aufs release.

Thanx for reporting, two of you.
J. R. Okajima

commit 348da45314afe6fc88e6f91a74da4587ec6555af
Author: J. R. Okajima hooanon05g@gmail.com
Date: Tue Nov 22 00:51:45 2016 +0900

aufs: dependency bugfix, linux/fs/mount.h

linux/fs/mount.h is included from two aufs source files,
fs/aufs/export.c and fs/aufs/vfsub.c.
For export.c, it is unnecessary which means a build dependency bug. The
bug was born back in 2012.
    c70a5cf 2012-01-13 aufs: tiny for 3.3, arg for iterate_mounts()
For vfsub.c, it is necessary and it is not a bug. But it is just for
CONFIG_AUFS_BR_FUSE only. So it should be refined by "#ifdef
CONFIG_AUFS_BR_FUSE".

Reported-by: Jan Luca Naumann <j.naumann@fu-berlin.de>
See-also: https://github.com/sfjro/aufs4-standalone/pull/1
Reported-by: Philipp Marek <philipp.marek@linbit.com>
See-also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843846
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

diff --git a/fs/aufs/export.c b/fs/aufs/export.c
index 2b2380a..afba472 100644

• --- a/fs/aufs/export.c
  +++ b/fs/aufs/export.c
  @@ -12,7 +12,6 @@
  #include <linux/nsproxy.h>
  #include <linux/random.h>
  #include <linux/writeback.h>

• -#include "../fs/mount.h"
  #include "aufs.h"

  union conv {
  diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c
  index f2d1b36..fc52351 100644

• --- a/fs/aufs/vfsub.c
  +++ b/fs/aufs/vfsub.c
  @@ -10,7 +10,9 @@
  #include <linux/nsproxy.h>
  #include <linux/security.h>
  #include <linux/splice.h>
  +#ifdef CONFIG_AUFS_BR_FUSE
  #include "../fs/mount.h"
  +#endif
  #include "aufs.h"

  #ifdef CONFIG_AUFS_BR_FUSE

------- End of Blind-Carbon-Copy