linux.git/fs/overlayfs/export.c, branch v6.5

ovl: deduplicate lowerpath and lowerstack[]

2023-06-19T11:01:13+00:00

The ovl_inode contains a copy of lowerpath in lowerstack[0], so the
lowerpath member can be removed.

Use accessor ovl_lowerpath() to get the lowerpath whereever the member
was accessed directly.

Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

ovl: move ovl_entry into ovl_inode

2023-06-19T11:01:13+00:00

The lower stacks of all the ovl inode aliases should be identical
and there is redundant information in ovl_entry and ovl_inode.

Move lowerstack into ovl_inode and keep only the OVL_E_FLAGS
per overlay dentry.

Following patches will deduplicate redundant ovl_inode fields.

Note that for pure upper and negative dentries, OVL_E(dentry) may be
NULL now, so it is imporatnt to use the ovl_numlower() accessor.

Reviewed-by: Alexander Larsson 
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

ovl: use ovl_numlower() and ovl_lowerstack() accessors

2023-06-19T11:01:13+00:00

This helps fortify against dereferencing a NULL ovl_entry,
before we move the ovl_entry reference into ovl_inode.

Reviewed-by: Alexander Larsson 
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

ovl: use OVL_E() and OVL_E_FLAGS() accessors

2023-06-19T11:01:12+00:00

Instead of open coded instances, because we are about to split
the two apart.

Reviewed-by: Alexander Larsson 
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

ovl: update of dentry revalidate flags after copy up

2023-06-19T11:01:12+00:00

After copy up, we may need to update d_flags if upper dentry is on a
remote fs and lower dentries are not.

Add helpers to allow incremental update of the revalidate flags.

Fixes: bccece1ead36 ("ovl: allow remote upper")
Reviewed-by: Gao Xiang 
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

fs: port ->permission() to pass mnt_idmap

2023-01-19T08:24:28+00:00

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner (Microsoft)

ovl: do not reconnect upper index records in ovl_indexdir_cleanup()

2022-12-08T09:49:46+00:00

ovl_indexdir_cleanup() is called on mount of overayfs with nfs_export
feature to cleanup stale index records for lower and upper files that have
been deleted while overlayfs was offline.

This has the side effect (good or bad) of pre populating inode cache with
all the copied up upper inodes, while verifying the index entries.

For copied up directories, the upper file handles are decoded to conncted
upper dentries.  This has the even bigger side effect of reading the
content of all the parent upper directories which may take significantly
more time and IO than just reading the upper inodes.

Do not request connceted upper dentries for verifying upper directory index
entries, because we have no use for the connected dentry.

Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi

ovl: fix comment typos

2022-12-08T09:49:46+00:00

Fix two typos.

Reported-by: k2ci 
Signed-off-by: Jiangshan Yi 
Signed-off-by: Miklos Szeredi

ovl: Use "buf" flexible array for memcpy() destination

2022-12-08T09:49:46+00:00

The "buf" flexible array needs to be the memcpy() destination to avoid
false positive run-time warning from the recent FORTIFY_SOURCE
hardening:

  memcpy: detected field-spanning write (size 93) of single field "&fh->fb"
  at fs/overlayfs/export.c:799 (size 21)

Reported-by: syzbot+9d14351a171d0d1c7955@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/000000000000763a6c05e95a5985@google.com/
Signed-off-by: Kees Cook 
Reviewed-by: Gustavo A. R. Silva 
Signed-off-by: Miklos Szeredi

ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh()

2022-07-28T13:00:57+00:00

Some code paths cannot guarantee the inode have any dentry alias. So
WARN_ON() all !dentry may flood the kernel logs.

For example, when an overlayfs inode is watched by inotifywait (1), and
someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD,
at that time if the dentry has been reclaimed by kernel (such as
echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The
printed call stack would be like:

    ? show_mark_fhandle+0xf0/0xf0
    show_mark_fhandle+0x4a/0xf0
    ? show_mark_fhandle+0xf0/0xf0
    ? seq_vprintf+0x30/0x50
    ? seq_printf+0x53/0x70
    ? show_mark_fhandle+0xf0/0xf0
    inotify_fdinfo+0x70/0x90
    show_fdinfo.isra.4+0x53/0x70
    seq_show+0x130/0x170
    seq_read+0x153/0x440
    vfs_read+0x94/0x150
    ksys_read+0x5f/0xe0
    do_syscall_64+0x59/0x1e0
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

So let's drop WARN_ON() to avoid kernel log flooding.

Reported-by: Hongbo Yin 
Signed-off-by: Jiachen Zhang 
Signed-off-by: Tianci Zhang 
Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles")
Cc:  # v4.16
Signed-off-by: Miklos Szeredi