Re: aufs3: remove include of linux/fs.h from linux/mm.h
On Sat, 2014-07-19 at 20:40 +0100, Ian Campbell wrote:
On Sun, 2014-07-20 at 02:38 +0900, sf...@users.sourceforge.net wrote:
Hello Ian,
Ian Campbell:
This include is added by aufs3-mmap.patch but causes circular
dependencies on arm64 as seen with the Debian kernel packages in
:::
According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
The added mm.h-fs.h looks like a mistake, it should not be there, and
we=
have
in the past worked hard to separate mm.h, sched.h and fs.h from one
anoth=
er.
Hmm, I didn't know such history...
Anyway I agree mmap approach in aufs is ugly in the terms of its logic
and looking. And I am afraid converting into macros looks still
bad-looking. Do you think can we do this?
- create a new file mm/aufs_mmap.c
- move the inline funcs to the new file.
- the calling macros are left in mm.h.
- function delarations are added in mm.h.
That sounds like a plausible plan to me.
The following patch which does what I think you are suggesting works OK
for me too.
8--
From: Ian Campbell i...@hellion.org.uk
Subject: aufs3: remove include of linux/fs.h from linux/mm.h
This include is added by aufs3-mmap.patch but causes circular dependencies on
arm64 as seen with the Debian kernel packages in
http://buildd.debian-ports.org/status/fetch.php?pkg=linuxarch=arm64ver=3.14.12-1stamp=1405234443
which contains:
In file included from /«PKGBUILDDIR»/include/linux/mm.h:23:0,
from /«PKGBUILDDIR»/include/linux/pid_namespace.h:6,
from /«PKGBUILDDIR»/include/linux/ptrace.h:9,
from /«PKGBUILDDIR»/arch/arm64/include/asm/compat.h:26,
from /«PKGBUILDDIR»/arch/arm64/include/asm/stat.h:23,
from /«PKGBUILDDIR»/include/linux/stat.h:5,
from /«PKGBUILDDIR»/include/linux/module.h:10,
from /«PKGBUILDDIR»/init/main.c:15:
/«PKGBUILDDIR»/include/linux/fs.h:1575:64: warning: 'struct kstat' declared
inside parameter list [enabled by default]
int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
The added mm.h-fs.h looks like a mistake, it should not be there, and we have
in the past worked hard to separate mm.h, sched.h and fs.h from one another.
Move all of the static inline functions added to mm.h by
aufs3-mmap.patch into a new file, mm/aufs_mmap.c, instead to avoid the
new includes in mm.h.
Signed-off-by: Ian Campbell i...@hellion.org.uk
Index: linux/include/linux/mm.h
===
--- linux.orig/include/linux/mm.h 2014-07-20 08:34:40.0 +0100
+++ linux/include/linux/mm.h2014-07-20 08:42:47.625617449 +0100
@@ -18,9 +18,6 @@
#include linux/pfn.h
#include linux/bit_spinlock.h
#include linux/shrinker.h
-#include linux/dcache.h
-#include linux/file.h
-#include linux/fs.h
struct mempolicy;
struct anon_vma;
@@ -1155,76 +1152,16 @@
}
#endif
-/*
- * Mainly for aufs which mmap(2) diffrent file and wants to print different
path
- * in /proc/PID/maps.
- */
-/* #define AUFS_DEBUG_MMAP */
-static inline void aufs_trace(struct file *f, struct file *pr,
- const char func[], int line, const char func2[])
-{
-#ifdef AUFS_DEBUG_MMAP
- if (pr)
- pr_info(%s:%d: %s, %p\n, func, line, func2,
- f ? (char *)f-f_dentry-d_name.name : (null));
-#endif
-}
-
-static inline struct file *vmr_do_pr_or_file(struct vm_region *region,
-const char func[], int line)
-{
- struct file *f = region-vm_file, *pr = region-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- return (f pr) ? pr : f;
-}
-
-static inline void vmr_do_fput(struct vm_region *region,
- const char func[], int line)
-{
- struct file *f = region-vm_file, *pr = region-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- fput(f);
- if (f pr)
- fput(pr);
-}
-
-static inline void vma_do_file_update_time(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- file_update_time(f);
- if (f pr)
- file_update_time(pr);
-}
-
-static inline struct file *vma_do_pr_or_file(struct vm_area_struct *vma,
-const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
- aufs_trace(f, pr, func, line, __func__);
- return (f pr) ? pr : f;
-}
-
-static inline void vma_do_get_file(struct vm_area_struct *vma,
- const char func[], int line)
-{
- struct file *f = vma-vm_file, *pr = vma-vm_prfile;
-
aufs3 GIT release
o bugfix - missing mnt_want_write in moo In move-up-on-open, between copying-up to the upper branch and unlinking on the lower branch, mnt_want_write is necessary. - restore the lost unlock in an error path A call to au_unpin() in an error path was lost by an old commit fb3f6aa 2013-04-21 Merge branch 'aufs3.5/00base' into aufs3.6/00base which got conflicts in git-merge and I fixed them manually. In this manual fix I made a mistake and a call to au_unpin() in an error path was lost. It means the last version of aufs3.6 - aufs3.8 has this bug and not fixed because they are not maintained now. o news - new ioctl BRINFO J. R. Okajima -- - aufs3-linux.git aufs: bugfix, missing mnt_want_write in moo aufs: tiny, move defs to uapi header aufs: new ioctl BRINFO aufs: bugfix, restore the lost unlock in an error path - aufs3-standalone.git ditto - aufs-util.git use the new brinfo interface tiny, move the clean target in Makefile tiny, forgot to list-up the new attributes libau: strip at the link-time distinguish CFLAGS and CPPFLAGS prepend override to every += in makefile refine make install target tiny, include optional libau/priv.mk -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
Re: aufs3: remove include of linux/fs.h from linux/mm.h
Ian Campbell: The following patch which does what I think you are suggesting works OK for me too. Thanks for the patch. #ifndef CONFIG_MMU was less important since the built kernel doesn't contain the functions defined in the header as long as they are unused. But by moving them into a source file, the built kernel will contain them. So ifndef CONFIG_MMU is necessary this time. I will merge your patch with adding ifndef CONFIG_MMU for vmr_* functions, and release next week. I hope you don't mind your Singed-off-by is left after my minor modification. J. R. Okajima -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
Re: Kernel oops after heavy filesystem work
James B: Update on the issue: I've decided to try another path - Russel King the ARM kernel maintainer has updated his cubox-i patches to work with 3.16-rc kernel (so now the cubox-i can run mainline kernel + his 40-odd patches). I have tried building 3.16-rc5 kernel with his patches (using aufs3.15 branch, since aufs3.x-rcN doesn't work for me) and I still got the same issue so far. Where can I get the source file? And is the address still 0x3f? If so, could try disassembling dput() and aufs_rename()? linux/Documentation/BUG-HINTING and oops-tracing will be helpful. Actually I have never read/write the assembly code on ARM. But I need to find out the cause of the mysterious address. J. R. Okajima -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
Re: aufs as root vor openvz CT
Sergey Korshunoff: Sorry, I'm back. The key of the problem with suspend/resume of the openvz container using aufs as a root fs is a file descriptor opened by aufs itself. For me, the key of the problem is - less description about the problem and the environment. - even after I quoted the necessary information from aufs README file, I got nothing. I won't be helpful for you until you give me enough information. Do you have any special reason not to give the information? J. R. Okajima -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
Re: aufs3: remove include of linux/fs.h from linux/mm.h
Ian Campbell: #ifndef CONFIG_MMU was less important since the built kernel doesn't contain the functions defined in the header as long as they are unused. But by moving them into a source file, the built kernel will contain them. So ifndef CONFIG_MMU is necessary this time. Yes, good point. Re-reading several makefiles, - fs/proc/Makefile builds nommu.o and task_nommu.o unconditionally. - mm/Makeilfe builds nommu.o unconditionally. So I change my mind and stop adding ifndef CONFIG_MMU. J. R. Okajima -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
