From: kernel test robot <lkp@intel.com>
To: Christian Brauner <brauner@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
"Seth Forshee (DigitalOcean)" <sforshee@kernel.org>
Subject: fs/namespace.c:3039: warning: Function parameter or member 'mp' not described in 'can_move_mount_beneath'
Date: Tue, 10 Oct 2023 22:53:57 +0800 [thread overview]
Message-ID: <202310102222.bAvU21dC-lkp@intel.com> (raw)
Hi Christian,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 94f6f0550c625fab1f373bb86a6669b45e9748b3
commit: 6ac392815628f317fcfdca1a39df00b9cc4ebc8b fs: allow to mount beneath top mount
date: 5 months ago
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20231010/202310102222.bAvU21dC-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231010/202310102222.bAvU21dC-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202310102222.bAvU21dC-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> fs/namespace.c:3039: warning: Function parameter or member 'mp' not described in 'can_move_mount_beneath'
vim +3039 fs/namespace.c
3015
3016 /**
3017 * can_move_mount_beneath - check that we can mount beneath the top mount
3018 * @from: mount to mount beneath
3019 * @to: mount under which to mount
3020 *
3021 * - Make sure that @to->dentry is actually the root of a mount under
3022 * which we can mount another mount.
3023 * - Make sure that nothing can be mounted beneath the caller's current
3024 * root or the rootfs of the namespace.
3025 * - Make sure that the caller can unmount the topmost mount ensuring
3026 * that the caller could reveal the underlying mountpoint.
3027 * - Ensure that nothing has been mounted on top of @from before we
3028 * grabbed @namespace_sem to avoid creating pointless shadow mounts.
3029 * - Prevent mounting beneath a mount if the propagation relationship
3030 * between the source mount, parent mount, and top mount would lead to
3031 * nonsensical mount trees.
3032 *
3033 * Context: This function expects namespace_lock() to be held.
3034 * Return: On success 0, and on error a negative error code is returned.
3035 */
3036 static int can_move_mount_beneath(const struct path *from,
3037 const struct path *to,
3038 const struct mountpoint *mp)
> 3039 {
3040 struct mount *mnt_from = real_mount(from->mnt),
3041 *mnt_to = real_mount(to->mnt),
3042 *parent_mnt_to = mnt_to->mnt_parent;
3043
3044 if (!mnt_has_parent(mnt_to))
3045 return -EINVAL;
3046
3047 if (!path_mounted(to))
3048 return -EINVAL;
3049
3050 if (IS_MNT_LOCKED(mnt_to))
3051 return -EINVAL;
3052
3053 /* Avoid creating shadow mounts during mount propagation. */
3054 if (path_overmounted(from))
3055 return -EINVAL;
3056
3057 /*
3058 * Mounting beneath the rootfs only makes sense when the
3059 * semantics of pivot_root(".", ".") are used.
3060 */
3061 if (&mnt_to->mnt == current->fs->root.mnt)
3062 return -EINVAL;
3063 if (parent_mnt_to == current->nsproxy->mnt_ns->root)
3064 return -EINVAL;
3065
3066 for (struct mount *p = mnt_from; mnt_has_parent(p); p = p->mnt_parent)
3067 if (p == mnt_to)
3068 return -EINVAL;
3069
3070 /*
3071 * If the parent mount propagates to the child mount this would
3072 * mean mounting @mnt_from on @mnt_to->mnt_parent and then
3073 * propagating a copy @c of @mnt_from on top of @mnt_to. This
3074 * defeats the whole purpose of mounting beneath another mount.
3075 */
3076 if (propagation_would_overmount(parent_mnt_to, mnt_to, mp))
3077 return -EINVAL;
3078
3079 /*
3080 * If @mnt_to->mnt_parent propagates to @mnt_from this would
3081 * mean propagating a copy @c of @mnt_from on top of @mnt_from.
3082 * Afterwards @mnt_from would be mounted on top of
3083 * @mnt_to->mnt_parent and @mnt_to would be unmounted from
3084 * @mnt->mnt_parent and remounted on @mnt_from. But since @c is
3085 * already mounted on @mnt_from, @mnt_to would ultimately be
3086 * remounted on top of @c. Afterwards, @mnt_from would be
3087 * covered by a copy @c of @mnt_from and @c would be covered by
3088 * @mnt_from itself. This defeats the whole purpose of mounting
3089 * @mnt_from beneath @mnt_to.
3090 */
3091 if (propagation_would_overmount(parent_mnt_to, mnt_from, mp))
3092 return -EINVAL;
3093
3094 return 0;
3095 }
3096
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2023-10-10 14:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 14:53 kernel test robot [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-12 16:19 fs/namespace.c:3039: warning: Function parameter or member 'mp' not described in 'can_move_mount_beneath' kernel test robot
2023-08-31 3:43 kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202310102222.bAvU21dC-lkp@intel.com \
--to=lkp@intel.com \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=sforshee@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.