GitLab

By the recent commit
	21913077f9918 2020-06-17 aufs: do not call i_readcount_inc()
a very old bug was fixed, which is inblance counter.
But still aufs needs to call i_readcount_inc() when the branch
permission is chaned from RW to RO.  Otherwise the counter reaches 0
and BUG() in i_readcount_dec() will be activated.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit f10aea57d39d6cd311312e9e7746804f7059b5c8)

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>

# Conflicts:
#	Documentation/filesystems/aufs/design/01intro.txt
#	Documentation/filesystems/aufs/design/02struct.txt
#	Documentation/filesystems/aufs/design/03atomic_open.txt
#	Documentation/filesystems/aufs/design/03lookup.txt
#	Documentation/filesystems/aufs/design/04branch.txt
#	Documentation/filesystems/aufs/design/05wbr_policy.txt
#	Documentation/filesystems/aufs/design/06dirren.txt
#	Documentation/filesystems/aufs/design/06fhsm.txt
#	Documentation/filesystems/aufs/design/06mmap.txt
#	Documentation/filesystems/aufs/design/06xattr.txt
#	Documentation/filesystems/aufs/design/07export.txt
#	Documentation/filesystems/aufs/design/08shwh.txt
#	Documentation/filesystems/aufs/design/10dynop.txt
#	fs/aufs/aufs.h
#	fs/aufs/branch.c
#	fs/aufs/branch.h
#	fs/aufs/cpup.c
#	fs/aufs/cpup.h
#	fs/aufs/dbgaufs.c
#	fs/aufs/dbgaufs.h
#	fs/aufs/dcsub.c
#	fs/aufs/dcsub.h
#	fs/aufs/debug.c
#	fs/aufs/debug.h
#	fs/aufs/dentry.c
#	fs/aufs/dentry.h
#	fs/aufs/dinfo.c
#	fs/aufs/dir.c
#	fs/aufs/dir.h
#	fs/aufs/dirren.c
#	fs/aufs/dirren.h
#	fs/aufs/dynop.c
#	fs/aufs/dynop.h
#	fs/aufs/export.c
#	fs/aufs/f_op.c
#	fs/aufs/fhsm.c
#	fs/aufs/file.c
#	fs/aufs/file.h
#	fs/aufs/finfo.c
#	fs/aufs/fstype.h
#	fs/aufs/hbl.h
#	fs/aufs/hfsnotify.c
#	fs/aufs/hfsplus.c
#	fs/aufs/hnotify.c
#	fs/aufs/i_op.c
#	fs/aufs/i_op_add.c
#	fs/aufs/i_op_del.c
#	fs/aufs/i_op_ren.c
#	fs/aufs/iinfo.c
#	fs/aufs/inode.c
#	fs/aufs/inode.h
#	fs/aufs/ioctl.c
#	fs/aufs/lcnt.h
#	fs/aufs/loop.c
#	fs/aufs/loop.h
#	fs/aufs/module.c
#	fs/aufs/module.h
#	fs/aufs/mvdown.c
#	fs/aufs/opts.c
#	fs/aufs/opts.h
#	fs/aufs/plink.c
#	fs/aufs/poll.c
#	fs/aufs/posix_acl.c
#	fs/aufs/procfs.c
#	fs/aufs/rdu.c
#	fs/aufs/rwsem.h
#	fs/aufs/sbinfo.c
#	fs/aufs/super.c
#	fs/aufs/super.h
#	fs/aufs/sysaufs.c
#	fs/aufs/sysaufs.h
#	fs/aufs/sysfs.c
#	fs/aufs/sysrq.c
#	fs/aufs/vdir.c
#	fs/aufs/vfsub.c
#	fs/aufs/vfsub.h
#	fs/aufs/wbr_policy.c
#	fs/aufs/whout.c
#	fs/aufs/whout.h
#	fs/aufs/wkq.c
#	fs/aufs/wkq.h
#	fs/aufs/xattr.c
#	fs/aufs/xino.c
#	include/uapi/linux/aufs_type.h

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)

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

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

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

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

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

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)