All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.