GitLab

The 'struct inode.i_readcount' field is maintained at the VFS, and
should not be modified by filesystems.  But aufs does in one place,
which causes it to be unbalanced.

This started with Linux v2.6.39 commit 890275b5eb79 ("IMA: maintain
i_readcount in the VFS layer"), which moved the i_readcount updates
from IMA into the VFS (at the same places IMA was called previously)
and introduced 'mutex_lock(i_mutex)' in the ima_file_check() path.

The former change is functionally equivalent, thus no changes are
needed in response to it.

The latter change, on the other hand, is _not_; and is reported to
cause a deadlock in aufs (see below), thus it dropped the call to
ima_file_check().

However, when dropping the ima_file_check() call, aufs introduced
the i_readcount_inc() call as well, which according to the commit
changes is not necessary.

This can be observed in aufs2-standalone.git commit 1dbd1c864e455
("aufs2.1 standalone version for linux-2.6."), announced to the
aufs-users mailing list on 2011-04-04 [1].

    diff --git a/ChangeLog b/ChangeLog
    ...
    +commit 17eac367b03334e57a93e8051eb712add24d2534
    +Author: J. R. Okajima <hooanon05@yahoo.co.jp>
    +Date:   Fri Apr 1 16:31:22 2011 +0900
    +
    +    aufs: for 2.6.39, limit the support for IMA
    +
    +    Since it acquires i_mutex and causes a deadlock, replace a
    +    ima_file_check() call by i_readcount_inc().
    +
    +    Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
    ...
    diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c
    ...
    struct file *vfsub_dentry_open(struct path *path, int flags)
    ...
    +       if (!IS_ERR_OR_NULL(file)
    +           && (file->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
    +               i_readcount_inc(path->dentry->d_inode);

    -       err = ima_file_check(file, au_conv_oflags(flags));
    ...

Apparently, this might have been a misunderstanding of one hunk in
the 2.6.39 commit, that deletes the lines to increment i_readcount,
and adds the lines to acquire i_mutex.

It reuses code from the removed function ima_counts_get() to create
ima_rdwr_violation_check(), and another hunk calls the new function
from ima_file_check().  But note that the i_readcount increment was
_not_ called from ima_file_check() previously, via ima_counts_get():

    -void ima_counts_get(struct file *file)
    +static void ima_rdwr_violation_check(struct file *file)
     {
    ...
    +       mutex_lock(&inode->i_mutex);    /* file metadata: permissions, xattr */
    ...
    -               atomic_inc(&inode->i_readcount);

    @@ -318,6 +308,7 @@ int ima_file_check(struct file *file, int mask)
    ...
    +       ima_rdwr_violation_check(file);

So, in order to avoid the unbalance caused to i_readcount, drop the
i_readcount_inc() call.

Note the issue is not the lack of a corresponding i_readcount_dec()
call; it's the mere usage of these functions outside of VFS layer,
where i_readcount is maintained.

Links:

[1] https://sourceforge.net/p/aufs/mailman/message/27304125/


    snippet:

    """
    aufs2 Monday GIT release
    From: <sfjro@us...> - 2011-04-04 04:59:18

    o news
    - begin supporting linux-2.6.39-rcN.
    ...
    - aufs2-2.6.git#aufs2.1 branch
    ...
          aufs: for 2.6.39, limit the support for IMA
    ...
    """
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
(cherry picked from commit 515a586eeef31e0717d5dea21e2c11a965340b3c)

SELinux's d_instantiate hook calls __vfs_getxattr() BEFORE d_inode is
set.  Aufs should not rely upon d_inode and should use the parameter
inode instead.
Reported-by: "jon bird" <news@onasticksoftware.co.uk>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 5777718fd657e1cfdf006cd16b524c65cf2fe09b)

In linux v5.7-rc2, zero-length array declarations are replaced by FAM
(flexible-array member),
	a2008395fe2e 2020-04-18 dirent.h: Replace zero-length array with flexible-array member

Aufs simply follows this trend.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 747a01ec1835988fa20177789a6fb65c5198fcb9)

In aufs5.4, kmemleak reported several false positives in
fs/aufs/xino.c.  I don't know why, but it may be related to the
"delayed" kfree (by RCU).  So I simply replace it by direct kfree()
call.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 03836b8128073f92b4e4a1cb54f91d0d7c290d1f)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 0f5f91bda77d0690c23732fd2592ae97c908a704)

These "+1" were left accidentally when refining the lookup routine.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 4177c438179671556de7312107c8aa766ea3d658)

When a branch filesystem doesn't cache ACL, aufs should not cache
either.  Until now aufs has never met such fs, but theoretically it
could happen.  Actually, in linux-v5.1-rc1, NFSv3 changed its behaviour
by the commit
	ded52fbe7020 2019-02-20 nfs: fix xfstest generic/099 failed on nfsv3
The commit ded52fbe7020 doesn't "forget" the previous acl though.
Doesn't it mean that the obsoleted acl is kept until NFS's attribute
cache is expired?  I don't know.  I've asked it on LKML, but got no
answer.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit e448daa00228186b869356fdef8d98d9f95caf53)

A compilation -Wimplicit-fallthrough warning was enabled by commit
a035d552a93b ("Makefile: Globally enable fall-through warning")
and triggers the following warning.

fs/aufs/opts.h:78:11:
warning: this statement may fall through [-Wimplicit-fallthrough=]

This patch adds comments according GNU manual.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

Signed-off-by: He Zhe <zhe.he@windriver.com>
See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05685.html
(cherry picked from commit e7619996b014c5d8fd2f6ad89542c545a207667f)

Add missing break statement for case Opt_wsum in au_opt_simple.
Signed-off-by: He Zhe <zhe.he@windriver.com>
See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05684.html
(cherry picked from commit 9e7d29356ab57fa5db7e92e51267176e50c1497c)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 4596850541ed7144f7fea951d02f0f6251c4a997)

The scenario is very similar to previous commit
"aufs: bugfix, ignore the being freed dynop object".
One exception is that this commit is for sbinfo object which is managed
by kobject (instead of kref).

In order to enter the plink-maintenance mode, users write an ID to
"/proc/fs/aufs/plink_maint" (this path is defined as macros in
include/uapi/linux/aufs_type.h).  If someone else is unmounting the
aufs mount corresponding that ID, then the searcher task may find a
being freed sbinfo object.
The problem and the fix is very similar to previous commit
"aufs: bugfix, ignore the being freed dynop object".
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 949b498ae30797b19b9e7ac9b230815f31ffe378)

Aufs DYNOP (Dynamically customizable FS operations) object is managed by
kref, and when its counter reaches zero, the callback function removes
the object from the internal list which is protected by a spinlock and
then frees the object.
Here there is a small time window between
A: the counter reaches zero, and
B: require the lock to remove the object from the list.
If someone else acquires the lock and searches the list, it may find the
counter-zero'ed object which means the object is being freed.
This commit ignores the object whose counter is already zero.
Reported-and-tested-by: Kirill Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit b633d7b2635b9615fe294b85257d05008e3747a3)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 9dbd45984201453ecebcc03a91699878aa38239d)

At the mount-time, XINO files are created and removed very soon.  When
multiple mounts with being given the same XINO file path executed in
parallel, some of them may fail in creating XINO due to EEXIST.
Introducing a local mutex, make it serialized.
By default, XINO is created at the top dir of the first writable
branch.  In this case, the new mutex won't be used.

Obviously this is an unnecessary overhead when the XINO file path is not
same, and such lock should be done by inode_lock() for the parent dir.
Actually au_xino_create2() behaves in this manner.  Then why didn't I
apply the same way to this au_xino_create()?  It is just because of my
laziness.  Calling VFS filp_open() here is easy for me.
Reported-by: Kirill Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 30d9273f2a1ce331b1a79b770bdb4c493919a673)

Although I am not sure module_exit is necessary for the statically
linked module, here is it.  I hope it does no harm.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

They are historical options and a branch attribute.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Fuse doesn't want the callers to access the inode attributes without
issuing stat, and it is not assured that they are valid after lookup or
iget().
The inode attribute is critical for aufs, and aufs decided to call stat
every time for fuse.
Of course, it makes aufs slow. But when the branch fs is not fuse, stat
is not called.

Currently, only FUSE implements ->poll(), and aufs supports it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Basically ramfs is limited for its size, and is not suitable for aufs RW
branch. But people sometimes use it as RW branch without knowing it or
with knowing it.
This configuration is for those who knows what he is doing.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Special support for filesystems which acquires an inode mutex at final
closing a file, eg, hfsplus.
This trick is very simple and stupid, just to open the file before really
necessary open to tell hfsplus that this is not the final closing.
The caller should call au_h_open_pre() after acquiring the inode mutex,
and au_h_open_post() after releasing it.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Still I am not sure how this feature breaches the security. Some people
say it doesn't matter. But I don't know.
Anyway upon the request from the users, aufs implements it as a module
option.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

It is ok that the branch is loopback-mounted.
But it had a problem if the backend fs-image is placed on another
branch, and aufs had prohibited such nested branch for a long time due
to the recursive lookup by 'loopN' daemon.
I don't remember when it was, but the daemon stopped such recursive
behaviour, but aufs is still prohibitting the nested branch via
loopback-mount.
Upon the request from users, aufs will allow the loopback-mounted branch
on another branch by another patch (aufs4-loopback.patch in
aufs4-standalone.git).
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This feature automatically handles MVDOWN in other commits.
In user-space, a daemon monitors the free space of the branch and issues
MVDOWN ioctl automatically when necessary. The main role is in
user-space and several options are implemented.
For a branch to join the FHSM circle, a new attribute 'fhsm' should be
specified.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When these attributes are specified and aufs tries opening a file on that
branch, aufs copies/moves it up.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Support for the options of MVDOWN feature, which allows to overwrite the
existing entry, and writing to the branch even if its permission is RO.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Another ioctl feature, move-down.
The behaviour is, as you can guess, the opposite of copy-up.
The feature called FHSM (file-based hierarchical storage management, in
later commit) uses this ioctl aggressively.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Because of some inode is in use, the deletion of a branch can fail.
For those who wants to test the inode is busy or not, aufs provides an
ioctl, and a utility 'aubusy' in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

For a directory which has millions of files, aufs VDIR consumes
much memory. In this case, RDU (readdir(3) in user-space) is definitely
better.
If you enable CONFIG_AUFS_RDU at compiling aufs, install libau.so from
aufs-util.git, and set some environment variables, then you can use this
feature. When readdir(3) in libau.so receives an aufs dir, it issues
ioctl(2) instead of regular readdir(3).
All merging and whiteout handling are done in userspace.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Provide info about the branches, which will be used from user-space.
This is essentially equivalent to the entries under sysfs
(/sys/fs/aufs/si_*/).
But the ioctl behaviour is atomic and never confuse the matching of the
branch id.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Provide a file descriptor corresponding the specified writable branch.
The file descriptor will be used from user-space such as FHSM and
libau.so. For details, see aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Print the current data status for debugging.
The trigger key is a module parameter and you can freely change. The
default is 'a' of course.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Simple checks when the module is loaded.
This feature is compiled when CONFIG_AUFS_DEBUG is enabled.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Aufs provides some info via debugfs such as
- the branch path
- the current number of pseudo-links
- the size and the number of consumed blocks by XINO, XIB and XIGEN.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

These are very old options.
Since Unionfs created 'diropq' unconditionally in mkdir(2), old users
may expect the same behaviour. But there are cases where 'diropq' is
unnecessary. The aufs default behaviour is to create 'diropq' only when
it is necessary.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Generally aufs hides the name of whiteouts. But in some cases, to show
them is very useful for users. For instance, creating a new middle layer
(branch) by merging existing layers.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

While most people (especially who use tmpfs as top writable branch)
doesn't care, I care and think it can be a security problem.
For example, when the lower readonly branch may contain
/etc/{passwd,shadow} and the permission bits of the upper empty
branch is world-writable, then a malicious user can make these files
manually with by-passing aufs.
Aufs can do nothing but produce a warning.

For details, see aufs manual in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Introduce the new mount options, dirren and nodirren, which activates
and deactivates DIRREN feature.
In remount and unmount, the inum-list per branch should be flushed to
the file.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When aufs meets a new dir inode on a branch in lookup, it tests whether
the inode is in the list which the branch has. If the inode is found, it
means the dir has ever been logically renamed and there is some info
about the name under that dir. Then aufs tries loading the info, and
continues looking up using the before-renamed name on the lower
branches.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When DIRREN is enabled and activated, the error case where
aufs rename(2) used to return EXDEV will be gone.
Aufs rename(2) registers the renaming dir inum to the list in the
branch, creates the detailed info file, and returns a success.

If udba=notify option is specified with dirren, the internal detection
may not work correctly since aufs may not be able to find the target
name.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The detailed info per renamed directory is stored in a regular file per
branch, ie. when each of two lower branches contains the same named
entry, then the created info files will be two.
The file is created internally by aufs rename(2) and loaded by lookup.
Also when the actual rename on the branch fails, the newly created or
stored info file should be all reverted.

When the renamed dir is renamed-back to the previous/original name, then
the info file has to be removed.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>