From: kernel test robot <lkp@intel.com>
To: gregkh@linuxfoundation.org, brauner@kernel.org,
amir73il@gmail.com, gscrivan@redhat.com, hch@lst.de,
linux-fsdevel@vger.kernel.org, mszeredi@redhat.com,
stable@vger.kernel.org
Cc: kbuild-all@lists.01.org
Subject: Re: FAILED: patch "[PATCH] exportfs: support idmapped mounts" failed to apply to 5.4-stable tree
Date: Tue, 7 Jun 2022 22:46:03 +0800 [thread overview]
Message-ID: <202206072252.SYRt38ih-lkp@intel.com> (raw)
In-Reply-To: <165451866750136@kroah.com>
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on hch-configfs/for-next]
[cannot apply to linus/master v5.19-rc1 next-20220607]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/intel-lab-lkp/linux/commits/gregkh-linuxfoundation-org/FAILED-patch-PATCH-exportfs-support-idmapped-mounts-failed-to-apply-to-5-4-stable-tree/20220606-203330
base: git://git.infradead.org/users/hch/configfs.git for-next
config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220607/202206072252.SYRt38ih-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/cda5e21742a0ec193c2dfd7e445a2024f9685eb9
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review gregkh-linuxfoundation-org/FAILED-patch-PATCH-exportfs-support-idmapped-mounts-failed-to-apply-to-5-4-stable-tree/20220606-203330
git checkout cda5e21742a0ec193c2dfd7e445a2024f9685eb9
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash fs/exportfs/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
fs/exportfs/expfs.c: In function 'reconnect_one':
fs/exportfs/expfs.c:148:15: error: implicit declaration of function 'lookup_one_unlocked'; did you mean 'lookup_one_len_unlocked'? [-Werror=implicit-function-declaration]
148 | tmp = lookup_one_unlocked(mnt_user_ns(mnt), nbuf, parent, strlen(nbuf));
| ^~~~~~~~~~~~~~~~~~~
| lookup_one_len_unlocked
>> fs/exportfs/expfs.c:148:13: warning: assignment to 'struct dentry *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
148 | tmp = lookup_one_unlocked(mnt_user_ns(mnt), nbuf, parent, strlen(nbuf));
| ^
cc1: some warnings being treated as errors
vim +148 fs/exportfs/expfs.c
108
109 /*
110 * Reconnect a directory dentry with its parent.
111 *
112 * This can return a dentry, or NULL, or an error.
113 *
114 * In the first case the returned dentry is the parent of the given
115 * dentry, and may itself need to be reconnected to its parent.
116 *
117 * In the NULL case, a concurrent VFS operation has either renamed or
118 * removed this directory. The concurrent operation has reconnected our
119 * dentry, so we no longer need to.
120 */
121 static struct dentry *reconnect_one(struct vfsmount *mnt,
122 struct dentry *dentry, char *nbuf)
123 {
124 struct dentry *parent;
125 struct dentry *tmp;
126 int err;
127
128 parent = ERR_PTR(-EACCES);
129 inode_lock(dentry->d_inode);
130 if (mnt->mnt_sb->s_export_op->get_parent)
131 parent = mnt->mnt_sb->s_export_op->get_parent(dentry);
132 inode_unlock(dentry->d_inode);
133
134 if (IS_ERR(parent)) {
135 dprintk("%s: get_parent of %ld failed, err %d\n",
136 __func__, dentry->d_inode->i_ino, PTR_ERR(parent));
137 return parent;
138 }
139
140 dprintk("%s: find name of %lu in %lu\n", __func__,
141 dentry->d_inode->i_ino, parent->d_inode->i_ino);
142 err = exportfs_get_name(mnt, parent, nbuf, dentry);
143 if (err == -ENOENT)
144 goto out_reconnected;
145 if (err)
146 goto out_err;
147 dprintk("%s: found name: %s\n", __func__, nbuf);
> 148 tmp = lookup_one_unlocked(mnt_user_ns(mnt), nbuf, parent, strlen(nbuf));
149 if (IS_ERR(tmp)) {
150 dprintk("%s: lookup failed: %d\n", __func__, PTR_ERR(tmp));
151 err = PTR_ERR(tmp);
152 goto out_err;
153 }
154 if (tmp != dentry) {
155 /*
156 * Somebody has renamed it since exportfs_get_name();
157 * great, since it could've only been renamed if it
158 * got looked up and thus connected, and it would
159 * remain connected afterwards. We are done.
160 */
161 dput(tmp);
162 goto out_reconnected;
163 }
164 dput(tmp);
165 if (IS_ROOT(dentry)) {
166 err = -ESTALE;
167 goto out_err;
168 }
169 return parent;
170
171 out_err:
172 dput(parent);
173 return ERR_PTR(err);
174 out_reconnected:
175 dput(parent);
176 /*
177 * Someone must have renamed our entry into another parent, in
178 * which case it has been reconnected by the rename.
179 *
180 * Or someone removed it entirely, in which case filehandle
181 * lookup will succeed but the directory is now IS_DEAD and
182 * subsequent operations on it will fail.
183 *
184 * Alternatively, maybe there was no race at all, and the
185 * filesystem is just corrupt and gave us a parent that doesn't
186 * actually contain any entry pointing to this inode. So,
187 * double check that this worked and return -ESTALE if not:
188 */
189 if (!dentry_connected(dentry))
190 return ERR_PTR(-ESTALE);
191 return NULL;
192 }
193
--
0-DAY CI Kernel Test Service
https://01.org/lkp
next prev parent reply other threads:[~2022-06-07 14:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 12:31 FAILED: patch "[PATCH] exportfs: support idmapped mounts" failed to apply to 5.4-stable tree gregkh
2022-06-07 14:46 ` kernel test robot [this message]
2022-06-07 17:07 ` kernel test robot
2022-06-07 18:08 ` Christian Brauner
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=202206072252.SYRt38ih-lkp@intel.com \
--to=lkp@intel.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=gscrivan@redhat.com \
--cc=hch@lst.de \
--cc=kbuild-all@lists.01.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).