All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH v3 1/3] fs: prepare for "explicit connectable" file handles
Date: Sat, 12 Oct 2024 01:21:54 +0800	[thread overview]
Message-ID: <202410112259.QfHlqgCD-lkp@intel.com> (raw)
In-Reply-To: <20241008152118.453724-2-amir73il@gmail.com>

Hi Amir,

kernel test robot noticed the following build errors:

[auto build test ERROR on brauner-vfs/vfs.all]
[also build test ERROR on linus/master v6.12-rc2 next-20241011]
[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#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Amir-Goldstein/fs-prepare-for-explicit-connectable-file-handles/20241008-232246
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all
patch link:    https://lore.kernel.org/r/20241008152118.453724-2-amir73il%40gmail.com
patch subject: [PATCH v3 1/3] fs: prepare for "explicit connectable" file handles
config: openrisc-allnoconfig (https://download.01.org/0day-ci/archive/20241011/202410112259.QfHlqgCD-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241011/202410112259.QfHlqgCD-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/202410112259.QfHlqgCD-lkp@intel.com/

All errors (new ones prefixed by >>):

   fs/exportfs/expfs.c: In function 'exportfs_decode_fh_raw':
>> fs/exportfs/expfs.c:447:24: error: returning 'int' from a function with return type 'struct dentry *' makes pointer from integer without a cast [-Wint-conversion]
     447 |                 return -EINVAL;
         |                        ^


vim +447 fs/exportfs/expfs.c

   434	
   435	struct dentry *
   436	exportfs_decode_fh_raw(struct vfsmount *mnt, struct fid *fid, int fh_len,
   437			       int fileid_type, unsigned int flags,
   438			       int (*acceptable)(void *, struct dentry *),
   439			       void *context)
   440	{
   441		const struct export_operations *nop = mnt->mnt_sb->s_export_op;
   442		struct dentry *result, *alias;
   443		char nbuf[NAME_MAX+1];
   444		int err;
   445	
   446		if (WARN_ON_ONCE(FILEID_USER_FLAGS(fileid_type)))
 > 447			return -EINVAL;
   448	
   449		/*
   450		 * Try to get any dentry for the given file handle from the filesystem.
   451		 */
   452		if (!exportfs_can_decode_fh(nop))
   453			return ERR_PTR(-ESTALE);
   454		result = nop->fh_to_dentry(mnt->mnt_sb, fid, fh_len, fileid_type);
   455		if (IS_ERR_OR_NULL(result))
   456			return result;
   457	
   458		if ((flags & EXPORT_FH_DIR_ONLY) && !d_is_dir(result)) {
   459			err = -ENOTDIR;
   460			goto err_result;
   461		}
   462	
   463		/*
   464		 * If no acceptance criteria was specified by caller, a disconnected
   465		 * dentry is also accepatable. Callers may use this mode to query if
   466		 * file handle is stale or to get a reference to an inode without
   467		 * risking the high overhead caused by directory reconnect.
   468		 */
   469		if (!acceptable)
   470			return result;
   471	
   472		if (d_is_dir(result)) {
   473			/*
   474			 * This request is for a directory.
   475			 *
   476			 * On the positive side there is only one dentry for each
   477			 * directory inode.  On the negative side this implies that we
   478			 * to ensure our dentry is connected all the way up to the
   479			 * filesystem root.
   480			 */
   481			if (result->d_flags & DCACHE_DISCONNECTED) {
   482				err = reconnect_path(mnt, result, nbuf);
   483				if (err)
   484					goto err_result;
   485			}
   486	
   487			if (!acceptable(context, result)) {
   488				err = -EACCES;
   489				goto err_result;
   490			}
   491	
   492			return result;
   493		} else {
   494			/*
   495			 * It's not a directory.  Life is a little more complicated.
   496			 */
   497			struct dentry *target_dir, *nresult;
   498	
   499			/*
   500			 * See if either the dentry we just got from the filesystem
   501			 * or any alias for it is acceptable.  This is always true
   502			 * if this filesystem is exported without the subtreecheck
   503			 * option.  If the filesystem is exported with the subtree
   504			 * check option there's a fair chance we need to look at
   505			 * the parent directory in the file handle and make sure
   506			 * it's connected to the filesystem root.
   507			 */
   508			alias = find_acceptable_alias(result, acceptable, context);
   509			if (alias)
   510				return alias;
   511	
   512			/*
   513			 * Try to extract a dentry for the parent directory from the
   514			 * file handle.  If this fails we'll have to give up.
   515			 */
   516			err = -ESTALE;
   517			if (!nop->fh_to_parent)
   518				goto err_result;
   519	
   520			target_dir = nop->fh_to_parent(mnt->mnt_sb, fid,
   521					fh_len, fileid_type);
   522			if (!target_dir)
   523				goto err_result;
   524			err = PTR_ERR(target_dir);
   525			if (IS_ERR(target_dir))
   526				goto err_result;
   527	
   528			/*
   529			 * And as usual we need to make sure the parent directory is
   530			 * connected to the filesystem root.  The VFS really doesn't
   531			 * like disconnected directories..
   532			 */
   533			err = reconnect_path(mnt, target_dir, nbuf);
   534			if (err) {
   535				dput(target_dir);
   536				goto err_result;
   537			}
   538	
   539			/*
   540			 * Now that we've got both a well-connected parent and a
   541			 * dentry for the inode we're after, make sure that our
   542			 * inode is actually connected to the parent.
   543			 */
   544			err = exportfs_get_name(mnt, target_dir, nbuf, result);
   545			if (err) {
   546				dput(target_dir);
   547				goto err_result;
   548			}
   549	
   550			inode_lock(target_dir->d_inode);
   551			nresult = lookup_one(mnt_idmap(mnt), nbuf,
   552					     target_dir, strlen(nbuf));
   553			if (!IS_ERR(nresult)) {
   554				if (unlikely(nresult->d_inode != result->d_inode)) {
   555					dput(nresult);
   556					nresult = ERR_PTR(-ESTALE);
   557				}
   558			}
   559			inode_unlock(target_dir->d_inode);
   560			/*
   561			 * At this point we are done with the parent, but it's pinned
   562			 * by the child dentry anyway.
   563			 */
   564			dput(target_dir);
   565	
   566			if (IS_ERR(nresult)) {
   567				err = PTR_ERR(nresult);
   568				goto err_result;
   569			}
   570			dput(result);
   571			result = nresult;
   572	
   573			/*
   574			 * And finally make sure the dentry is actually acceptable
   575			 * to NFSD.
   576			 */
   577			alias = find_acceptable_alias(result, acceptable, context);
   578			if (!alias) {
   579				err = -EACCES;
   580				goto err_result;
   581			}
   582	
   583			return alias;
   584		}
   585	
   586	 err_result:
   587		dput(result);
   588		return ERR_PTR(err);
   589	}
   590	EXPORT_SYMBOL_GPL(exportfs_decode_fh_raw);
   591	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2024-10-11 17:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 15:21 [PATCH v3 0/3] API for exporting connectable file handles to userspace Amir Goldstein
2024-10-08 15:21 ` [PATCH v3 1/3] fs: prepare for "explicit connectable" file handles Amir Goldstein
2024-10-08 18:19   ` Jeff Layton
2024-10-08 20:31     ` Amir Goldstein
2024-10-10 11:01       ` Amir Goldstein
2024-10-11 11:03   ` kernel test robot
2024-10-11 11:29     ` Amir Goldstein
2024-10-11 17:21   ` kernel test robot [this message]
2024-10-08 15:21 ` [PATCH v3 2/3] fs: name_to_handle_at() support " Amir Goldstein
2024-10-08 18:31   ` Jeff Layton
2024-10-08 19:43     ` Amir Goldstein
2024-10-08 15:21 ` [PATCH v3 3/3] fs: open_by_handle_at() support for decoding " Amir Goldstein
2024-10-08 18:37   ` Jeff Layton
2024-10-08 20:01     ` Amir Goldstein
2024-10-09  7:17 ` [PATCH v3 0/3] API for exporting connectable file handles to userspace Amir Goldstein

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=202410112259.QfHlqgCD-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=amir73il@gmail.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    /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.