Re: [PATCH 10/13] xfs: use get_unused_fd_flags(0) instead ofget_unused_fd()

[Dave Chinner]

On Wed, Jul 10, 2013 at 12:00:57PM +0200, Yann Droneaud wrote:
> Hi,
> 
> Le 09.07.2013 22:53, Ben Myers a écrit :
> >On Mon, Jul 08, 2013 at 05:41:33PM -0500, Ben Myers wrote:
> >>On Tue, Jul 02, 2013 at 06:39:34PM +0200, Yann Droneaud wrote:
> 
> >>> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> >>> index 5e99968..dc5b659 100644
> >>> --- a/fs/xfs/xfs_ioctl.c
> >>> +++ b/fs/xfs/xfs_ioctl.c
> >>> @@ -248,7 +248,7 @@ xfs_open_by_handle(
> >>>  		goto out_dput;
> >>>  	}
> >>>
> >>> -	fd = get_unused_fd();
> >>> +	fd = get_unused_fd_flags(0);
> >>
> >>O_CLOEXEC should be fine in this case.
> >>
> >>Reviewed-by: Ben Myers <bpm@xxxxxxx>
> >
> >Applied at git://oss.sgi.com/xfs/xfs.git.  Looks like I was wrong about
> >O_CLOEXEC being ok here.  There may be applications which
> >open_by_handle then
> >fork/exec and expect to still be able to use that file descriptor.
> >
> 
> OK, it's very important to not cause regression here.
> 
> For the record, xfs_open_by_handle() is not related to
> open_by_handle_at() syscall.
> 
> It's an ioctl (XFS_IOC_OPEN_BY_HANDLE) which is used by xfsprogs's
> libhandle
> in functions open_by_fshandle() and open_by_handle().
> 
> http://sources.debian.net/src/xfsprogs/3.1.9/libhandle/handle.c?hl=284#L284
> http://sources.debian.net/src/xfsprogs/3.1.9/libhandle/handle.c?hl=308#L308
> 
> According to codesearch.debian.org, libhandle's open_by_handle() is
> only used
> by xfsdump
> 
> http://sources.debian.net/src/xfsdump/3.1.1/restore/tree.c?hl=2534#L2534
> 
> So there's no many *known* users of this features ... but it's more
> important
> not to break *unknown* users of it.

There are commercial products (i.e. proprietary, closed source) that
use it. SGI has one (DMF) and there are a couple of other backup
programs that have used it in the past, too.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/