o misc
- for v4.17-rc1, no more open_check_o_direct()
J. R. Okajima
- aufs4-linux.git#aufs4.x-rcN branch
aufs: for v4.17-rc1, no more open_check_o_direct()
- aufs4-standalone.git
ditto
- aufs-util.git
nothing
o news
- linux-v4.17 is released, so is aufs4.17.
- linux-v4.15 is marked as EOL, so is aufs4.15.
o misc
- open_check_o_direct() strikes back in mainline.
- update the donators list.
J. R. Okajima
- aufs4-linux.git#aufs4.9..aufs4.16 branch
aufs:
Hello all,
This is a preannouncement.
When linux-v4.18.0 comes, I will switch my development base to v4.14.
Current base is v4.9, so aufs4.9..aufs4.13 will be unsupported.
J. R. Okajima
--
Check out the vibrant tech
o news
- now aufs4.x-rcN branch supports linux-v4.18-rc2. This is first 4.18
series aufs supports since the build system in v4.18-rc1 was broken.
- aufs XINO handling is refined drastically and become truly sharable
between branches who are on the same device.
- there are "xiN" entries on
Cc address is switched from linux-fsdevel ML to aufs-users.
Prasad Koya:
> <1>[45257161.254682] BUG: unable to handle kernel NULL pointer
> dereference at 0038
> <1>[45257161.351193] IP: [] au_do_open_nondir+0x3b/0xaf
:::
> 43 finfo = au_fi(file);
> 44
o news
- aufs4.9.94+ and aufs4.14.56+ branches are released.
Because aufs4-loopback.patch needs to be updated, reported by Jerome
Tamba.
Note that aufs4.9 series will end soon, so aufs4.9.94+ will be the
most short lived version.
J. R. Okajima
Prasad Koya:
> >>> So your kernel is vanilla v3.4.43 and aufs is plain 3.4-20130325, right?
> We have few custom patches on top of vanilla kernel and some backports
> from 3.18.
So your kernel has these components,
- vanilla v3.4.43
- your patches
- aufs3.4-20130325
I don't know what your bug is
Prasad Koya:
> and finally we switch root (in busybox still) before launching init
>
> exec switch_root -c /dev/console /newroot /sbin/init
Before you run switch_root, I'd suggest you to try "mount --move" to
make branch fs visible.
$ for i in newroot-overlay squashed-root
do
mkdir
I forgot writing one thing.
Prasad Koya:
> - Lower is ro squashfs
Are you sure?
There is no squashfs entry in your /proc/mounts.
J. R. Okajima
--
Check out the vibrant tech community on one of the world's most
Prasad Koya:
> Linux version 3.4.43
:::
> [0.420566] aufs 3.4-20130325
So your kernel is vanilla v3.4.43 and aufs is plain 3.4-20130325, right?
As you might know, the last version of aufs3.4 is aufs3.4-20131104.
As a first step, I'd suggest you to use the last version.
And how did
sf...@users.sourceforge.net:
> Hello all,
>
> This is a preannouncement.
> When linux-v4.18.0 comes, I will switch my development base to v4.14.
> Current base is v4.9, so aufs4.9..aufs4.13 will be unsupported.
Now I switched my development base to v4.14, ie. aufs4.14.
aufs4.9..aufs4.13 are not
o News
- linux-v4.18 is released, and aufs4.18 comes too.
This release has nothing new except aufs4.18 branch.
And aufs4.18 will lead aufs4.9..aufs4.13 branch to their end.
J. R. Okajima
--
Check out the vibrant tech
o news
- the XINO file becomes an array so that a huge inode numbers on the
branch fs are fully supported now.
J. R. Okajima
- aufs4-linux.git#aufs4.14..aufs4.x-rcN branch
aufs: minor, make au_xino_file_set() static
aufs: minor, convert the
Hello Lawrence,
Lawrence Jones:
> 2. Start container, and attempt to mount the /image loop device
>
> root@39d1cc6bc2d0:/# mkdir /data
> root@39d1cc6bc2d0:/# mount /image /data
> mount: block device /image is write-protected, mounting read-only
>
> What I suspect is happening here (though I have
Hello Jerome,
Jerome Tamba:
> 1. linux-4.14.y:
:::
> 2. linux-4.9.y: this happens from v4.9.94 onward. For reference:
:::
> 3. For linux-4.4.y, but I suspect this might not be as important since
:::
Thank you very much for your good analysis and report.
It is really
Hello Qian,
Qian Zhang:
> Can anyone please let me know if aufs supports POSIX ACLs (i.e., run the
> command "setfacl" to set ACL for file/directory)? If the answer is yes,
> then which version of aufs supports it?
It is supported since the version aufs3.9 20141208.
9f0b20e 2014-12-07 aufs3.9
Qian Zhang:
> And can you please let me know how to know the version of the aufs that I
> have installed on my Ubuntu 14.04 machine? I can see "nodev aufs"
> in /proc/filesystems, but I am not sure the version of it.
The basic way is the version string printed at loading aufs module.
But, in
There is nothing special in this release.
Minor or tiny commits only.
J. R. Okajima
- aufs4-linux.git#aufs4.9..aufs4.13 branch
aufs: minor, perm-bits in octal representation
- aufs4-linux.git#aufs4.14..aufs4.x-rcN branch
Addition to above,
o minor
- consolidate the xino initialization for a branch
J. R. Okajima
- aufs4-linux.git
aufs: consolidate the xino initialization for a branch
- aufs4-standalone.git
ditto
- aufs-util.git
nothing
Qian Zhang:
> I see there is a field "version:3.13-20140303", this should be the
> version of the installed aufs, right?
Probably you are right.
But I am not sure whether ubuntu people changed the aufs source files
with the version string unchanged.
If it is really 20140303, then it means
Hello Floris,
Floris Bos:
> I am getting compilation errors when cross-compiling for 32-bit ARM.
:::
> Probably caused by the 64-bit divisions in the new au_xi_calc() code not
> being natively supported on 32-bit architectures.
> Think you need to call do_div() or similar instead.
Thanx
o News
- Now master and aufs4.x-rcN branches in this release support
linux-v4.19-rcN.
Note that aufs4.x-rcN branch is still under testing.
o Bugfix
- possible bugfix, pass h_file as expected
- possible bugfix, remove sbinfo->si_xino_brid
- temp workaround for atomic_open on nfs4 branch
J.
o news
- a new mount option 'ephemeral' has come which is equivalent to
'droplvl=3.' in other words, it is just a shortcut to
noatime,dirperm1,udba=none,nodirren,notrunc_xino,notrunc_xib,noplink,noxino
J. R. Okajima
-
o News
- new aufs4.14.73+ branch for linux-v4.14.73 and later
tmpfs-idr.patch is updated, reported by tomjokiel.
o misc.
- tiny, fix misspelling
- tiny, make it sure RENAME_EXCHANGE is within u8
J. R. Okajima
- aufs4-linux.git
aufs: tiny, fix
This release doesn't update master and aufs4.x-rcN branches, but
contains a possible bugfix.
o bugfix
- possible bugfix, search XINO unwritten yet
J. R. Okajima
- aufs4-linux.git
aufs: update the donators list
aufs: possible bugfix, search
Mark Asselstine:
> As stated in tools/objtool/Documentation/stack-validation.txt the use
> of "Dynamic jumps and jumps to undefined symbols" has several
> conditions, neither of which we meet. The use of .label to dictate
> which label we 'goto' can be implemented in several ways that will be
>
Regulary I release new aufs every Monday. But it is Sunday today. Why?
Beacause very strong typhoon is coming again, and e-power may stop on
Monday...
o Bugfix
- the positive return value from aufs_atomic_open()
o Misc.
- br_nfiles and br_count 1/2, minor, br_nfiles can allow deleting a branch
o News
- aufs4.18.11+ branch for linux-v4.18.11 and later is released.
tmpfs-idr.patch is updated. reported by Kirk Puppy.
J. R. Okajima
- aufs4-linux.git#aufs4.14..aufs4.18 branch
nothing
- aufs4-linux.git#aufs4.18.11+ branch
aufs4.18.11+
This release doesn't contain aufs4.x-rcN branch for linux-v4.19-rc1
since I'm still testing.
o news
- As a part of xino-array feature in last release, division and modulo
operations were added into xino.c, and some versions of GCC generate
an internal function call for those operations. But
Hello Carsten,
Carsten Rose:
> probably I missed something: I would like to overlay a read only mounted
> nfs share with a local directory. That's fine, including writing in the
> overlay directory itself. But if write to a sub directory of the
> overaly, I get 'Operation not supported'.
I
o minor
- remove the sibling call warning, reported by Mark Asselstine.
o misc.
- for v4.20-rc1, type loff_t vfs_clone_file_range()
J. R. Okajima
- aufs4-linux.git#aufs4.14..aufs4.19 branch
aufs: minor, remove the sibling call warning
-
o minor
- try kfree_rcu()
- lockdep-debug.patch in aufs4-standalong.git is updated which tries
re-using the unused slot in static array lock_classes[]. But I am
still working on it.
This is the last aufs release in this year from me.
Have nice holidays!
J. R. Okajima
o News
- Now my local tests for linux-v4.19-rc3 (aufs4.x-rcN branch) has succeeded.
- aufs ->atomic_open() (mainly for NFSv4 branch) is massively refined.
o Bugfix
- br_count in aufs_atomic_open()
J. R. Okajima
- aufs4-linux.git
aufs: minor,
This release doesn't contain the updates for aufs5 series.
NFSv3 has a problem in linux-v5.1-rc1 and I am working on it.
o minor
- There are several EXPORT_SYMBOLS_GPLs in aufs patch file in
aufs4-standalone.git. They are necessary to build aufs as an external
module. But due to a
o News
- linux-v5.0 is released, and aufs5 comes with new two GIT repositories,
aufs5-linux.git and aufs5-standalone.git. Both are on github now.
These two repositories contain aufs5.0 and aufs5.x-rcN branches, they
are equivalent currently.
- aufs4.x-rcN branch in aufs4-linux.git is
This release doesn't contain the changes in the source code which affect
the behaviour of aufs. This is just to update the year in the Copyright
sentence.
J. R. Okajima
- aufs4-linux.git
aufs: tiny, update the year in Copyright
-
o news
- linux-v4.20 was released. So here is aufs4.20.
- linux-v4.19.17 and v4.20.4 contains a commit around the loopback block
device, and it conflicts with aufs4-loopback.patch. Here the patch is
updated. Reported by Arkadiusz Miskiewicz and Kirk Puppy.
J. R. Okajima
sf...@users.sourceforge.net:
> If we have a patch to the kernel-space, will it help you? Or is it
> unusable for you?
I'd like to propose this patch against /proc/mounts as a first solution,
and the previous ProcMount_Times patch (default is 1) as the second best
solution.
Does it help you?
J.
Kirill Kolyshkin:
> I was testing my aufs-related fixes to dockerd, and came upon this kernel
> oops:
>
> # dmesg
>
> [35180.792125] [ cut here ]
> [35180.792127] kernel BUG at
> /build/linux-3btXxq/linux-4.15.0/fs/aufs/dynop.c:207!
:::
> I'm not sure I can
o bugfix
- protect creating XINO from concurrent mounts, reported by Kirill
Kolyshkin.
- tiny, missing a parameter declaration
o misc
- a new kernel patch 'proc_mounts.patch' in aufs[45]-standalone.git
/proc/mounts is unreliable when concurrent umount(2) is issued. This
patch generates the
Kirill Kolyshkin:
> Awesome, and thanks for the fix! Are you in touch with Ubuntu kernel team?
>
> I am asking as it makes sense to ask them to backport this fix,
I am not a user of Ubuntu, nor a developer of Ubuntu kernel.
I'd suggest you to ask them as one of their user.
J. R. Okajima
Kirill Kolyshkin:
> I am still unable to reproduce it with patched aufs kernel module, but got
> a different oops on a different unpatched system:
That is a good news.
> Jun 04 21:38:38 kir-ubu1604 kernel: [ cut here ]
> Jun 04 21:38:38 kir-ubu1604 kernel: WARNING: CPU:
sf...@users.sourceforge.net:
> Kirill Kolyshkin:
> > The only way to make sure is to retry reading /proc/mounts. Or, do
> > stat+statfs
> > (exactly as you suggested below) to check that this is indeed the aufs root
> > directory (and then you still need to retry reading /proc/mounts).
>
> Give me
Kirill Kolyshkin:
> That was my first idea -- that I was replacing aufs module during this time.
> But systems logs shows no trace of that.
You mean that you want some msg about unloading aufs or removing the
entry under procfs? If so, here attached an example patch.
> I am pretty sure dockerd
o bugfix
- ignore the being freed dynop object, reported and tested by Kirill Kolyshkin
- ignore the being freed sbinfo object
- no nested RCU for kfree()
J. R. Okajima
- aufs4-linux.git
aufs: bugfix, ignore the being freed dynop object
aufs:
Kirill Kolyshkin:
> During my weeks of extensive stress testing of aufs I noticed this bug
> happened twice on one of the servers:
>
> May 31 20:05:42 kirtest dockerd[3912]:
> time="2019-05-31T20:05:42.686603244Z" level=warning msg="auplink flush
> failed: auplink:plink.c:158: proc: No such file
Hello Kir,
Thank you very much for your patch.
Kir Kolyshkin:
> 1. By looking into strace output, it looks like default buffer
> for fread() (and thus getmntent()) is only 1K, while a line in
> /proc/self/mounts can easily be more than 4K.
> Set the libc reading buffer to 4K, as this is a page
Kirill Kolyshkin:
> So yes, this is a problem with a kernel (and I confirmed it talking to
> a couple of kernel devs I know).
>
> It is probably too complicated to fix (without introducing an alternative
> kernel interface to access info mount point data, that is), so we have
> to live with it.
Kirill Kolyshkin:
> Oh, by the way, is there a way to let my (past) messages go through to
> the aufs-users mailing list? I did not know I need to be subscribed in order
> to post, and now I only see your replies in the list archives, but not my
> messages. The reason I'm asking is I wanted to
Kirill Kolyshkin:
> Sure, please let me know what needs improvement, I can spend some
> more time on that.
Here is what I did after applying your patch.
9f4976b 2019-05-23 minor, make-var ProcMounts_Times
84d1126 2019-05-23 minor, check AUFS_SUPER_MAGIC
eceb779 2019-05-23 tiny, replace
Kirill Kolyshkin:
> Can you tell me what is your reason to not retry reading by default? The
> code
> has just checked that this is an aufs mount so it should definitely be
> present in
> /proc/mounts. Unless, of course, this mount was unmounted by someone in
> between statfs() and reading. If you
Kirill Kolyshkin:
> The only way to make sure is to retry reading /proc/mounts. Or, do
> stat+statfs
> (exactly as you suggested below) to check that this is indeed the aufs root
> directory (and then you still need to retry reading /proc/mounts).
Give me some more time about this topic. I will
o news
- linux-v5.1 is released, and aufs5.1 follows it. But NFSv[34] didn't
pass my local tests. I've posted the problems to LKML, but got no
reply. I hope someday the problems will be solved.
J. R. Okajima
- aufs5-linux.git#aufs5.0 branch
Kirill Kolyshkin:
> It happens in Docker's aufs graph driver (which does not use mount.aufs
> but rather calls mount() syscall directly, and does the same for umount
> except it calls auplink flush beforehand). Previously, we had a global lock
:::
So your scenario is
- taskA:
+ assume
o News
- linux-v5.2 is released and hers is aufs5.2.
but nothig is changed since 20190610 version.
J. R. Okajima
- aufs5-linux.git
aufs5.2 is released
- aufs5-standalone.git
ditto
- aufs-util.git
nothing
Simply follow the changes in mainline v5.3-rc2.
linux-v5.3-rc1 was unusable, but the critical bug was fixed now.
When linux-v5.3 comes out, my develop base version will be linux-v4.19
and aufs4.1[4-8] will be obsoleted.
J. R. Okajima
- aufs4-linux.git
"J. R. Okajima":
> To see the current branches, refer to /sys/fs/aufs/si_*/*.
Also you may want to try the module parameter called 'brs'.
(from aufs manual)
Module Parameters
brs=1 | 0
Specifies to use the branch path data file under sysfs or not.
If
"Zhengyuan Liu":
> There is bug with v5.4 aufs when doing following operations:
>
> $mkdir a b c d
> $echo aa >a/a.txt
> $echo bb >b/b.txt
> $echo cc >c/c.txt
> $mount -v -t aufs -o br=/root/a:/root/b:/root/c none /root/d
> $cat /root/d/*
I cannot reproduce the problem.
It worked
"Zhengyuan Liu":
> Yes, ubuntu-focal.git/master-next updates too fast. I am using
> 0ff1d85115fe ("UBUNTU: Ubuntu-5.4.0-66.74"), and that corresponds to
> "5.4.86". It doesn't matter, latest master-next should reproduce this
> problem too.
I think I could reproduce the problem using 0ff1d85115fe
> This time I reinstalled a new Ubuntu 20.04.1 LTS and reinstall the kernel with
> CONFIG_AUFS_DEBUG enabled, the kernel src of Ubuntu 20.04.1 LTS is from
> https://kernel.ubuntu.com/git/ubuntu/ubuntu-focal.git/log/?h=master-next
> After that, the problem is still here.
Now I am trying to
Alon Zahavi:
> # When executing _open_shadow from dirUSB, the capabilities should not
> works (because nosuid)
> + getcap ./dirUSB/_open_shadow
> ./dirUSB/_open_shadow = cap_dac_read_search+eip
> + ./dirUSB/_open_shadow
> [1]4372 segmentation fault (core dumped) ./dirUSB/_open_shadow
Do you
hooanon...@gmail.com:
> Alon Zahavi:
> > # When using the aufs copy_up, the driver "copies" it with the capabilities.
> > + touch ./aufs-root/_open_shadow
> > + getcap -r ./
> > ./dir2/_open_shadow = cap_dac_read_search+eip
> > ./aufs-root/_open_shadow = cap_dac_read_search+eip
> >
Alon Zahavi:
> I understand but think you may consider taking more security measures in
> regards to the problem. For example, one way to overcome this issue is to
> check if a copy-up-ed file is a capable file, and if it is, strip the
> capabilities from it. Another mitigation is to check at the
He Zhe:
> As PREEMPT_RT started to be enabled in mainline since 5.3, this can also be
> helpful for mainline.
>
> Yocto project regularly integrates aufs into its kernel tree, where there are
> a number of users of preempt-rt and aufs.
Ok, I will put your patch in aufs5-standalone.git tree.
Mauricio Faria de Oliveira:
> There's a misunderstanding here, apparently. Sorry if this wasn't
> clear, but the request wasn't for testing w/ fuse; it was for testing
> more code paths to check for no regressions. The code path that
> depended on fuse is only the path used to reproduce the
Mauricio Faria de Oliveira:
> So, could you please run it through your internal test suite?
I've fixed the missing path.mnt problem, slightly tested with RW ntfs-3g
branch, and seen many issues as much as I have to stop the test.
The fundamental problem around RW fuse branch didn't change.
Some
Hi Mauricio,
Mauricio Faria de Oliveira:
> The key change is very simple (set `path.mnt` in vfsub_lookup_one_len())
> but its caller chain is large enough (reviewed/modified ~30 functions).
> Fortunately most of them already had `path.mnt` set or easy to obtain.
Thanx for the report. You made a
Hi Tomas,
Tomas M:
> Although I am not PeeBee, and I recognize that your email was not
> directed at me, I feel compelled to share my thoughts as a long-time
> AUFS user. I hope my perspective may assist you in making good
> decision.
Yes, you are definetly one of the oldest aufs user.
And I
"J. R. Okajima":
> - git repositories for aufs6 will appear in a week or two.
I was going to create new repositores for aufs6 on github, but I
couldn't. aufs5-linux.git on github is a fork of torvalds/linux.git,
and github doesn't allow me to create a new fork of the repository which
I already
Hi,
Guan Xin:
> Does this look ok? --
> mount -t aufs -o br=3D${BR1_ATTR}:${PATH_TO_BR1} -o
> br=3D${BR2_ATTR}:${PATH_TO_BR2}
> which is equivalent to
> mount -t aufs -o br=3D${BR1_ATTR}:${PATH_TO_BR1},br=3D${BR2_ATTR}:${PATH_=
> TO_BR2}
> (Special characters need to be escaped in the latter
Thomas Wei schuh:
> > "br=/upper=rw:/lower=ro" is not bad but I feel weird.
>
> This feels ok for me.
For me, "A = B = C" looks strange because B is a path and C is its
attribute.
But I start making myself feel "there is no problem here."
> For example overlayfs uses
"J. R. Okajima":
> Now I am thinking about changing mount.aufs(8) helper.
> - users specify "br:path1:path2" as usual.
> - mount.aufs helper (in aufs-util.git) translate it into
> "br=path1:path2" and executes /bin/mount with -i option, which stops
> calling mount.aufs again.
>
> I'm still
72 matches
Mail list logo
