On Wed, 15 Oct 2008, Christoph Hellwig wrote:
> As Miklos pointed out a while ago returning NULL from the export
> operations and thus d_obtain_alias is not a good idea - the callers
> in exportfs convert it to an -ESTALE anyway (or as the audit pointed
> out don't deal with it at all in case of ->get_parent), and possibly
> returning either NULL or an ERR_PTR value form one function is
> confusing. By auditing the callers I also found various other places
> that couldn't deal with the NULL return. I guess an unlikely error
> path of an unlikely pass like this simply doesn't get tested.
Looks good, except:
> Index: vfs-2.6/fs/xfs/linux-2.6/xfs_ioctl.c
> ===================================================================
> --- vfs-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-10-11 04:48:36.000000000 -0400
> +++ vfs-2.6/fs/xfs/linux-2.6/xfs_ioctl.c 2008-10-11 04:52:34.000000000 -0400
> @@ -312,7 +312,7 @@ xfs_open_by_handle(
> }
>
> dentry = d_obtain_alias(inode);
> - if (dentry == NULL) {
> + if (IS_ERR(dentry)) {
> put_unused_fd(new_fd);
> return -XFS_ERROR(ENOMEM);
should be
return -XFS_ERROR(-PTR_ERR(dentry));
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
