There is no new feature nor bugfix in this release. Its aufs5.x-rcN
branch for linux-v5.3-rc3 simply follows the changes in mainline to be
compiled.
J. R. Okajima
- aufs5-linux.git#aufs5.0..aufs5.2 branch
nothing
- aufs5-linux.git#aufs5.x-rcN branch
o news
- for linux-v4.9.9 and later, aufs4.9.9+ branch is released
which includes a bugfix reported by Tony Lewis.
J. R. Okajima
- aufs4-linux.git#aufs4.9.9+ branch
aufs: version 4.9.9+
aufs: for v4.10, XINO(read) handles EINTR from the dying
Eddie Horng:
> I also tested "find" with the kernel version(4.10.0-34-generic) I
> reported f2474d8 case, after 1~3 ctrl-c to find, it does blocked, but
> the difference is in this case, dmesg doesn't report any process
> "blocked for more than 120 seconds", nothing printed in dmesg after
> find is
Tony Lewis:
> This fixes it, at least for my simple 'find' test.
:::
> So, to integrate this properly into my kernel (and not being a git guru)
> should I leave that cherry pick in place, or wait for your release into
> the 4.9 kernel next week?
Thank you for the test.
To use or not to u
Tony Lewis:
> Thanks. If you notify the mailing list when it's available, I'll give
> it a go. I have a slight preference for staying on the stable repo.
If you can, could you try testing the previous fix on your system?
$ cd /your/aufs4-standalone.git
$ git checkout origin/aufs4.9
$ git cherry-p
Tony Lewis:
> Thanks. I pulled the latest version from the standalone git repo, and
> checked out the latest 4.9 version (20180409 from memory). It compiled
> using DKMS and got loaded.
>
> But the problem still persisted. I don't know if you're interested in
> debugging further, I can help a bi
Hello Tony,
Tony Lewis:
> I find three symptoms:
>
> 1. If I do a 'find' command on the aufs-mounted directory (e.g. 'find
> /mnt/merge/data -print') it starts fine. If I do Ctrl-C to terminate,
> it doesn't. I cannot kill the find command even with kill -9 as root
>
> 2. If I have used the moun
o news
- linux-v4.16 is released, so here is aufs4.16.
there is no change to support the new version in aufs files, since the
branch aufs4.x-rcN already supported linux-v4.16-rcN.
o misc
- tiny, refine a few AuDbg() recently added
- minor, update the copyright year
J. R. Okajima
---
o bugfix
- minor, replace AuTraceErr() by AuDbg(), reported by Dengke Du and
Kexin(Casey) Chen.
- aufs4-linux.git
aufs: minor, replace AuTraceErr() by AuDbg()
- aufs4-standalone.git#aufs4.9 branch
ditto
- aufs-util.git
nothing
---
please ignore this.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
o news
- aufs4.15 is released, and aufs4.x-rcN supports linux-v4.16-rc1 now.
- aufs4.1[23] are now EOL.
o misc
- for v4.16-rc1, support for new iversion system
- for v4.16-rc1, finally inode_lock_shared_nested() is defined
- for v4.16-rc1, use __poll_t
For the new feature, iversion, in mainline,
Hello Peter,
"Smith, Peter1 (GE Power)":
> Hi, not sure if this is the correct mailing list but here goes. I'm working=
> on a custom distribution which uses the aufs-util recipe from the rocko ve=
> rsion of meta-openembedded/meta-filesystems. I have had trouble with the co=
> mpilation step whi
The master branch in this release doesn't follow the latest mainline. It
is still v4.5-rc5. And aufs4.15 is not ready yet. It's just because I am
busy. But also I guess aufs4.x-rcN branch will work well with
linux-v4.15.
Anyway aufs4.15 will be released in a few weeks.
o bugfix
- for v4.10, XINO(r
Eddie Horng:
> Many thanks you fixed the issue. May I consult you the theory of your
> fixing? Does au_wkq_wait() put vfs_read to an interrupt free stat so that
> read can complete without interrupt error? Just curious.
Many thanx to you for your repeated tests.
The workqueue is a kernel thread, a
Eddie Horng:
> Thanks your analysis, I'll deploy the patch to my environment.
I guess it will be a good indicator to find a cpu-eater when the problem
happens. If some other process eats a single cpu up, then the process
may repeat calling xino_fread.
J. R. Okajima
-
Eddie Horng:
> Got another report of hung case. The user said he ctrl-c the build job --
> similar operation to the xino_fread case we're verifying, but this time the
> hung process is rm and call stack is not exactly identical. Do you think
> this is the same case or it could be the fix you mentio
Eddie Horng:
> The patch works great! Applied the patch I can't reproduce the problem
> anymore, when func(file, buf.u, size, pos) returns -EINTR, "if (err ==
> -EINTR && !au_wkq_test() ..." entered and I never see i>1 case. Is this
> patch the final solution for this case?
Glad to hear that!
Well
Eddie Horng:
> I doubt that clang++.real has special file i/o or some signal handling that
> trigger the scenario, there're many kinds of processes are running in
> android building but the only busy looping process is always the same one
> in all my reproducing test. BTW, the return value from " e
Eddie Horng:
> It seems all tasks are trying to lock sbinfo->si_xib_mtx, but log shows
> nobody is holding it. I also got similar problem in my codefs, but it's
> very rare, not like this case now I can almost always reproduce it. To
> isolate issue, I changed ro branch from codefs to ext4 and stil
Eddie Horng:
> Log attached - related to previous mail
Thanx a lot.
But unfortunately there was not good info in the log.
I am still reviewing my aufs code. At the same time I start wondering
the problem may exist out of aufs. I know such probability is very
small.
Reviewing the code, I will prep
Eddie Horng:
> Thanks the information, but I still can reproduce it with aufs-4.10 and the
> held lock patch.
Hmm...
I am totally confused and lost my way. I don't understand what is
happening. If anyone on this list has an idea which light up the way, I
will be gladly become all ears.
Your repor
> But I have a suggestion for you.
>
> 1. upgrade your aufs to the latest aufs4.10.
>This is my very best recommendation.
:::
Ah, I forgot one thing.
Here is a debug patch to see the problem more clearly.
This is not a fix, but it may help to see more in the held lock list.
J. R. Oka
sf...@users.sourceforge.net:
> Exactly.
> At the same time, I noticed that I made a mistake on my git-work. I
> thought there is something wrong with the commit
> e14748e 2017-02-19 UBUNTU: SAUCE: Import aufs driver
> in zesty because it doesn't match the commit
> 6c73f3b 2017-02-04 auf
Eddie Horng:
> Yes, my kernel is git://kernel.ubuntu.com/ubuntu/ubuntu-zesty.git @tag:
> Ubuntu-4.10.0-34.38.
> I diff fs/aufs from my codebase, changes from zesty#1bfb6eb and
> aufs4#6c73f3b are:
> fs/aufs/cpup.c
> fs/aufs/vfsub.h
> for your reference if these diffs are as you expected.
Exactly.
Eddie Horng:
> I reproduced a hung case, maybe not exactly the same operation as original
> one but au_xino_delete_inode is appeared in call stake. Below dmesg log
> with lockdep enabled, please kindly check it.
Ok, I think I can find the AB-BA deadlock problem.
I will try fixing it asap. Please w
Hello Eddie,
Eddie Horng:
> I got hung to access to an aufs mount dir, dmesg shows mutex_lock call
> stack in aufs.
:::
> kernel version: 4.10.0-34-generic
> aufs version: 4.x-rcN-20170206
Hmm, your version is rather old, almost a year ago. But I don't think it
important.
> dmesg log:
Hi Tomas,
Glad to hear from you again.
Tomas M:
> can I use aufs mount as a branch of another aufs mount?
Basically, you can't.
Technically, such hierarchy will cause an internal recursive call which
consumes the stack space a lot. Aufs explicitly prohibited it in the
beginning. Later, another us
Hello IVan,
Next time when you post and report a problem, please attach these info.
(from aufs README file)
--
When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (instead of the outpu
o minor
- remove a harmless warning about the internal file-close, reported by
Ralf Jung.
J. R. Okajima
- aufs4-linux.git
aufs: remove a warning about the internal file-close
- aufs4-standalone.git
ditto
- aufs-util.git
nothing
o minor
- for linux-v4.15-rc2, replace MS_* flags by SB_*
J. R. Okajima
- aufs4-linux.git#aufs4.9..aufs4.14 branch
nothing
- aufs4-linux.git#aufs4.x-rcN branch
aufs: minor, for linux-v4.15-rc2, replace MS_* flags by SB_*
- aufs4-standalone.git
o minor
- update the standalone patch for aufs4.x-rcN (for linux-v4.15-rc1) in
order to export __devcgroup_check_permission().
- SPDX GPL-2.0 license identifier
J. R. Okajima
- aufs4-linux.git#aufs4.9..aufs4.13 branch
nothing
- aufs4-linux.git#aufs4.1
Linux-v4.14 is released, and aufs4.14 too.
Nothing is changed in aufs code.
J. R. Okajima
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
There was an editing failure in last release (aufs4.12 and later
branches), and lockdep_print_held_locks() call would cause a compilation
error. This release contains the fix for it.
o misc
- cosmetic, fix a too long line
- fix an editing failure
- tiny, remove an unused macro
---
Hi,
Eddie Horng:
> I have another workaround is to touch all dirs right after aufs mount, this
> will force aufs always return copied-up file handle, although the cost is
> extra time and space, but it does work for me to complete the building of
> my codebase.
Here is another workaround from me.
o news
- aufs4.12 and later, there introduces a new debugging scheme for the
internal rwsem. Ah, no. It is not so new. It just start using the
generic LOCKDEP feature in mainline. Before linux-v4.12, LOCKDEP was
not enough for aufs to use. By using LOCKDEP the aufs debugging code
becomes mu
Eddie Horng:
> I noticed that ls(1) and "stat ." work but getcwd(2) still fail after those
> commands, I got so confused when I just beginning to understand this issue.
Yes, that is why I wrote that I could not reproduce in the beginning.
All commands I have tried worked.
I might be confused too.
Eddie Horng:
> Glad to hear you reproduced, yes, make print getcwd warning and continue
> without error (sorry I didn't mention it clearly), but some applications
> stops if getcwd fails, for example python raise exception in os.getcwd().
>
> I tried your nfs client/server without aufs case, yes it
sf...@users.sourceforge.net:
> This looks like an NFS natural behaviour.
> Hmm, I have to think more in order to make NFS server to address this
> case. But it might be impossible.
I could reproduce half of the problem.
Running make got getcwd's error, but make didn't abort. It continued
running a
Eddie Horng:
> I printed some logs of above test case, looks like my trace in initial post
> is not exactly correct, d_invalidate is not directly call from mkdir
> syscall, but I think mkdir triggers nfsd send a changed file handler then
> d_invalidate is eventually invoked.
Ok, so the scenario is
Eddie Horng:
> VFS does re-lookup the dropped dentry, but seems only happened if there's a
> user-mode command trigger it, for example "cd ."
> Look at below log, the dropped dentry instance 0x8fc22d3066c0 is
> exactly the one getcwd used and is unlinked no matter how many times getcwd
> is cal
Eddie Horng:
> I printed some logs of above test case, looks like my trace in initial post
> is not exactly correct, d_invalidate is not directly call from mkdir
> syscall, but I think mkdir triggers nfsd send a changed file handler then
> d_invalidate is eventually invoked.
I don't think d_drop()
sf...@users.sourceforge.net:
> I have confirmed on Ubuntu-4.10.0-34.38 kernel. The kernel configuration
> is for my test environment, so it must be different from yours. But I am
> not sure whether the config is related.
I mean that I could not reproduce the problem.
J. R. Okajima
-
Eddie Horng:
> e. in step 8, mkdir invokes nfs_lookup_revalidate
> f. server side again run into: nfsd -> nfsd_lookup -> aufs::aufs_encode_fh
> g. this time, aufs_encode_fh returns filehander of folderA in br0(rw)
> i. in nfs_lookup_revalidate, nfs_compare_fh(NFS_FH(inode), fhandle) is
> called aft
Hello Eddie,
Eddie Horng:
> I encountered a getcwd() failure problem on a NFS mounted dir, in server
> side, the dir is aufs mounted.
> This problem can be always reproduced as below steps:
:::
Thanx for the detailed report and the analysis.
But I could not reproduce the problem on my tes
Hello Bogdan,
Bogdan Kiselitsa:
> I'm seeing a null dereference followed by an uninterruptible sleep when
> trying to rsync some stuff to my aufs mount. It's made up of 5 disks with
> varying filesystems (ext4, zfs, btrfs -- yes I'm testing some out).
:::
> Oct 12 21:25:02 bohdy-store kern
This release is less important. It is mainly to update main branch and
to follow the mainline.
o misc
- tiny, silence checkpatch.pl
- tiny, refine a header inclusion
J. R. Okajima
- aufs4-linux.git
aufs: tiny, silence checkpatch.pl
aufs: tiny,
o bugfix
- possible bugfix, deref RCU ptr, current->real_parent
o minor
- aufs doesn't depend upon linux/fs/mount.h anymore.
- for v4.12-rc1, use sb_rdonly()
J. R. Okajima
- aufs4-linux.git#aufs4.9..aufs4.13 branch
aufs: possible bugfix, deref RCU p
o news
- a new feature called DIRREN is implemented, which supports logical
renaming a dir who has his children on the multiple branches. Aufs
used to return EXDEV error for those cases.
Note that I don't like this feature and I am sure it is slow.
o misc
- minor, convert sphl (spinlock+hlis
Linux-v4.13 is released.
Now I've switched my base development version to v4.9.
J. R. Okajima
sf...@users.sourceforge.net:
> Hello all,
>
> Now the mainline is going to release linux-v4.13 (currently it is rc5).
> When v4.13 appears, all versions between aufs4.4 -- aufs4.8 will be
> obsoleted. T
o news
- linux-v4.13 is released, so is aufs4.13.
- this is the last release for aufs4.4..aufs4.8. now my development base
is aufs4.9.
o bugfix
- fanotify deadlock, reported by Ariel Zelivansky.
- aufs-util.git: libau: Define STRIP weakly, reported and fixed by Khem
Raj.
J. R. Okajima
-
Aufs-4.x-rcN branch in this release is against linux-v4.13-rc7.
o bugfix
- aufs4.11, include mm_types.h explicitly, reported by TAMUKI Shoichi.
- aufs4.12 loopback.patch, my local GIT-work failure, reported by
Pro-pra via github.
o minor
- for v4.7, more inode_lock_shared().
J. R. Okajima
-
TAMUKI Shoichi:
> I think it is better to modify aufs4.12 branches and later, too.
Of course.
All changes in aufs branches of the previous version will be
inheritated.
> I am looking forward to next Monday.
A single round of a single version takes over 8 hours now.
Let's pray with our fingers c
TAMUKI Shoichi:
> This temporary fix for arm architecture seems to be good. Now, we
> have to consider the parmanent fix for the official aufs patch. I
> wonder why the current aufs4.11.7+ fails to compile the kernel on arm
> architecture even though there has been no problem until aufs4.10.
I'v
TAMUKI Shoichi:
> This temporary fix for arm architecture seems to be good. Now, we
> have to consider the parmanent fix for the official aufs patch. I
> wonder why the current aufs4.11.7+ fails to compile the kernel on arm
> architecture even though there has been no problem until aufs4.10.
Exa
Hello TAMUKI-san,
TAMUKI Shoichi:
> However, aufs4.11.7+ fails to compile the kernel on arm architecture.
>
> Note, the kernel compilation with aufs4.11.7+ on x86 architecture
> works with no problem.
>
> Step to reproduce the problem:
Unfortunately it is hard for me to reproduce the problem sinc
No news is good news.
This release doesn't change aufs code at all. This is just to
follow the mainline linux-v4.13-rcN and v4.12.
- aufs4.12 branch is released.
- aufs4.x-rcN branch in this release is for linux-v4.13-rc5.
J. R. Okajima
--
Hello all,
Now the mainline is going to release linux-v4.13 (currently it is rc5).
When v4.13 appears, all versions between aufs4.4 -- aufs4.8 will be
obsoleted. The maintenance for them will stop. And the base development
version will be aufs4.9 since linux-v4.9 is marked as long-term version.
A
o news
- aufs4.11.7+ branch is released.
linux-v4.11.0 has a bug which is a show-stopper for my local
tests. now the fix is merged in linux-v4.11.7. Note that
aufs4.11.0-untested is essentially unsupported. For v4.11 series, use
v4.11.7 or later, and aufs4.11.7+.
J. R. Okajima
--
o news
- aufs4.11.0-untested branch for linux-v4.11.0 is created.
Note that this branch didn't pass my local tests because of a bug in
mainline(drm/i915). When linux-v4.11.x which contains the fix is
released, I will release aufs4.11.x+ for v4.11.x and later
kernels. aufs4.11.x+ will be ful
sf...@users.sourceforge.net:
> Here is a refined one. If you build aufs module by yourself. Use this.
:::
> commit eaa5a0db8e6977c884cb0d3c99f30c91d3aaba50
> Author: J. R. Okajima
> Date: Fri Jun 9 07:44:36 2017 +0900
>
> aufs: bugfix, copy-up using clone_file_range() on XFS branch
>
Vasily Tarasov:
> Just to clarify, by "the fix won't be included in next Monday release" you
> mean that you won't push this change to the public git until then?
>
> Sorry, I'm not too familiar with Aufs release policy...
Basically I release or used to release aufs every Monday. Needless to
say, w
Vasily Tarasov:
> Here is the content of the files:
Ok, thanx.
I could reproduce the problem on my local aufs4.11 (not 4.11.3), and
here is a fix for you.
Even if everything goes well, the fix won't be included in next Monday
release since it is too late.
J. R. Okajima
commit aa77e32fdb0a56fed2
I do not see aufs4.11 branch in
>
> https://github.com/sfjro/aufs4-linux
>
> Do I look in the wrong place?
Ah, sorry.
aufs4.11 is not released yet because of a bug in mainline.
I know that a patch already exists, but it is not merged into v4.11.x
series yet.
Anyway aufs4.x-rcN-201705
Hello Vasily,
Vasily Tarasov:
> 1. Writing in the *middle* of the file fails from inside the container with
> ENOSUP error. Writes do work without errors if I overwrite the whole file
> from the start.
> 2. Underlying file system is XFS. If I use Ext4 it works.
> 3. My aufs version is 4.x-rcN-2017
Hi,
Philip Muller:
> ERROR: "ilog2_NaN" [fs/aufs/aufs.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:90: __modpost] Error 1
> make: *** [Makefile:1106: modules] Error 2
>
> Any clue what might create this issue?
It might be related to your compiler.
See this commit in mainline.
Befor
The mainline v4.12-rc1 doesn't pass my test due to drm/i915 shrinker (as
well as v4.11). So do aufs4.x-rcN branch in this release.
I have aufs4.11 branch in my hand but don't release it because
linux-v4.11 doesn't pass my test. When v4.11.X is fine, I will release
aufs4.11.X. It should not be so lo
sf...@users.sourceforge.net:
> Linux-v4.11 is released, and aufs4.11 is ready too. But I won't release
> it. Because of i915/drm shrinker problem in mainline.
> http://marc.info/?l=linux-kernel&m=149353250528487&w=2
>
> I hope the fix (which already exists) will be merged into mainline until
> 4.11
Hello all,
Linux-v4.11 is released, and aufs4.11 is ready too. But I won't release
it. Because of i915/drm shrinker problem in mainline.
http://marc.info/?l=linux-kernel&m=149353250528487&w=2
I hope the fix (which already exists) will be merged into mainline until
4.11.1 or .2. Then I will releas
"Graw, Mathis":
> Actually we are having no chroot afaik, what we do is we are mounting an sd=
> -card copying the most of the sd card into ram and overlaying the root fs T=
> o the stuff in the ram with aufs.
Ok, then where is the file /usr/lib/systemd/libsystemd-shared-231.so
actually? (the file
"Graw, Mathis":
> as discusses I send out the needed data form my problem with aufs. To downl=
> oad the used kernel sources and all the data provided here as well
> please use the following link:
Ok, but don't you have sysfs?
> > - /sys/fs/aufs/* (if you have them)
These entries are very import
o news
- fine-grained xino lock
It should be a little help for the performance, just a little.
J. R. Okajima
- aufs4-linux.git
aufs: fine-grained xino lock 1/2, callee
aufs: fine-grained xino lock 2/2, caller
- aufs4-standalone.git
ditto
o news
- for linux-v4.5, support for copy_file_range(2).
o misc
- for linux-v4.5, use vfs_clone_file_range() in copy-up
J. R. Okajima
- aufs4-linux.git#aufs4.4 branch
none
- aufs4-linux.git#aufs4.5..aufs4.x-rcN branch
aufs: for v4.5, use vfs_clo
o news
- linux-v4.10 is released, and here is aufs4.10. Also aufs4.x-rcN start
supporting linux-v4.11-rcN.
- new mount option droplvl=N, which gains a performance in return for
the features. Use it carefully.
J. R. Okajima
- aufs4-linux.git#aufs4.4..a
Hello all,
sf...@users.sourceforge.net:
> The current base version of aufs development is linux-v4.1. And the
> latest mainline version is v4.10-rc5. When v4.10 is released, I will
> stop maintaining aufs4.[123] versions and the new base will be aufs4.4.
> I hope you don't mind.
Now linux-v4.10 a
"M. J. Everitt":
> I'm a bit confused that all the Gentoo instructions point to using a
> Hardened sources kernel .. I don't (yet) see a reason why, as Philip's
> patches work fine on 3.12.52 "gentoo-sources" . If anyone has any
> suggestions as to why this might (have) be(en) the case, it would f
o minor
- convert pid bitmap to a flag per task
- tiny, update the copyright year
Currently git.code.sf.net site rejects all connections from me. It
answers to ping, but unable to connect on ssh and https.
$ ssh -v sf...@git.code.sf.net
:::
debug1: Connecting to git.code.sf.net [216.34.18
o news
- for aufs: make __sync_filesystem() global, and export it
- aufs-util.git, libau.so: limit the exported symbols
J. R. Okajima
- aufs4-linux.git#aufs4.1..aufs4.9 branch
for aufs: make __sync_filesystem() global
aufs: refine aufs_sync_fs
This release contains a possible bugfix about syncfs(2), but the commit
is not enough. It will be refined soon.
o bugfix
- possible bugfix, missing s_umount rwsem for branch fs' sync_fs
- for v4.9, support posix acl, reported by Justin Cormack.
- aufs-util.git libau: closedir, clear errno explicit
OmegaPhil:
> Cheers - just out of interest, do you know how to set a watchpoint on
> errno in gdb? That wouldve saved a lot of time. It seems gdb is only
> capable of using errno in an expression when it suits it...
In our ancient age, the global errno was just a intger variable. In
these days, e
"M. J. Everitt":
> Thanks for that, I'll give that a roll, see how I get on. Hopefully that
> will be all!
Good luck, but there is an irritating situation.
The list in my previous mail is the difference between aufs3.12.31+ and
aufs3.13, but I don't know whether all these commits are merged into
v
OmegaPhil:
> I understand what you are saying from the manpage, however it does seem
> reasonable to say that any unusual errno state means a failure has
> occurred somewhere (ignoring the fact that released libau currently sets
> EBADF even when a failure has not happened).
>
> If I report this to
Hello all,
The current base version of aufs development is linux-v4.1. And the
latest mainline version is v4.10-rc5. When v4.10 is released, I will
stop maintaining aufs4.[123] versions and the new base will be aufs4.4.
I hope you don't mind.
J. R. Okajima
--
Hello Michael,
"M. J. Everitt":
> I was attempting to apply the aufs3 kernel patches to a 3.12.52 kernel
> I'm running under Gentoo linux, but the patchset for 3.12.31+ now fails.
> I contacted the Gentoo maintainer[1] who pointed me to this kernel
> commit[2], which tallies with my results of pat
Yair Yarom:
> Thanks, the patch works for me (we're usually not using acl, and that's
> what I've checked).
Thanks.
The patch will be included in next aufs release after my local tests
which takes several days.
J. R. Okajima
--
Hello OmegaPhil,
OmegaPhil:
> The actual problem is happening in git's
> sha1_file.c:prepare_packed_git_one, the closedir call right at the
> bottom is setting errno to 'Bad file descriptor', git later on notices
> that errno is bad and panics (ironically the fetch itself looks good).
>
> Any ide
o. Please test this patch.
You will need "acl" mount option for aufs to gain the full support of
posix-acl.
By the way, Justin's original post to this ML was not delivered to me. I
just got one line "cc @sfjro" msg from him, which was posted to
https://github.com/docker/docker
"Demmel Nikolaus (BOSP/PAR)":
> I'm assuming from your response that in general you expect AUFS to work wit=
> h PREEMPT_RT, or is this not the case?
Although I myself don't use RT patch, yes it should work. Of course,
some workaround may be necessary. It won't be clear until lots of tests
and di
Arun Chandran:
> "sudo mount .." gives correct labels. I can't use it because the
> containers don't get sudo inside ; container might be running with the
> lowest possible privileges.
Our discussion about the smack label is almost done. Thank you.
But I'd suggest you to consider other docker sto
Arun Chandran:
> No with 'sudo mount ..' the .wh.* files are created with label of the
> user test not with the label of root.
> [This is because objects gets label of the process; label of user test
> is "k1"; sudo is not changing label]
I see.
It may be a very basic building block of security l
Hello Nikolaus,
"Demmel Nikolaus (BOSP/PAR)":
> we are using AUFS for our root filesystem with an tmpfs overlay and recentl=
> y wanted to switch to a kernel with PREEMPT_RT patch. Unfortunately, it see=
> ms that mounting aufs seems to hang about 40% of the time during boot (ther=
> e is no spec
Arun Chandran:
> No, It succeeded and created with label "k1", please see below
Ok, then let's make sure again.
- you wrote that the smack label for root user is "_".
- "sudo mount -t aufs ..." created the file with access="_".
- "sudo touch ..." created with access="k1".
Why didn't "touch" and
Arun Chandran:
> # id
> uid=1001(test) gid=1001(test) groups=1001(test)
:::
> # cd layer1/
> # >.wh..wh.aufs
> # ln .wh..wh.aufs .wh.0.txt
Ok, succeeded with a normal user.
How about as a superuser?
cd layer1
sudo touch .wh..wh.aufs
ln .wh..wh.aufs .wh.0.txt
Is .wh..wh.aufs created with
Arun Chandran:
> -
> Files in the layers before mounting
> --
> # for i in `find layer* `; do chsmack $i; done
> layer0 access="k1"
> layer0/0.txt access="k1"
> layer1 access="k1"
> layer1/1.txt access="k1"
At
Arun Chandran:
> This happens because aufs handles removal of files through newly
> created file "layer1/.wh..wh.aufs"(I am guessing this from the below
> printk), as this file got created during the mount operation it is
> labeled as "_"
Still I don't get the point.
Would you try these steps? I
Arun Chandran:
> # mount -t aufs -o br=./layer2=rw:./layer1=ro:./layer0=ro -o
> udba=reval -o noplink,smackfsdef=k1,smackfsroot=k1 none ./rootfs_mnt
I'd suggest you to specify and test smack options on layerN instead of
rootfs_mnt.
Aufs is a virtual filesystem and it doesn't have a backend block
Arun Chandran:
> Now I moved my testing to 4.1.17(Used origin/aufs4.1.13+ from
> aufs4-standalone + b.patch applied).
>
> As a root user mounted the layers:
> # mount -t aufs -o
> br=./layer2=rw:./layer1=ro:./layer0=ro:,noplink,smackfsdef=k1,smackfsroot=k1
> -o udba=reval none ./rootfs_mnt/
Arun Chandran:
> Are you going to fix this in your tree? Please feel free to ask my
> help in testing it, I will happily do it.
Thanx for testing.
As you might know, aufs3.19 is not maintained now. So the tree won't be
updated anymore. But similar issue will happen in aufs4.1 and later. I
mean th
Arun Chandran:
> Thank you for the quick reply.
> I have tested the patch. 'ls' behavior is the same, it hangs. There
> are no error messages coming now may be it is doing something inside
> au_h_path_getattr() with holding the lock (When printed locked is -1).
Ah, it was necessary for au_h_path_g
Hello Arun,
Arun Chandran:
> 4) Now if I cd to /mnt/mnt and do 'ls' it hangs and I get the below oops.
>
>
> # dmesg
> [ 148.855382] [ cut here ]
> [ 148.855382] kernel BUG at fs/aufs/sbinfo.c:336!
:::
That is interesting.
Smack enters aufs twice.
Generally a sy
o bugfix
- dependency bugfix, linux/fs/mount.h, reported by Jan Luca Naumann and
Philipp Marek.
o news
- linux-v4.9 is released, so is aufs4.9.
+ support new rename flags.
- new create policy tdmfs, requested by Brenden Carvalho.
Currently there are two known problems in aufs.
- "MAX_LOCKDE
1 - 100 of 2717 matches
Mail list logo
