[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70a3a6971c3127226563e9538ae53bec@meuh.org>
Date: Wed, 10 Jul 2013 12:00:57 +0200
From: Yann Droneaud <ydroneaud@...eya.com>
To: Ben Myers <bpm@....com>
Cc: linux-kernel@...r.kernel.org, xfs@....sgi.com, ydroneaud@...eya.com
Subject: Re: [PATCH 10/13] xfs: use get_unused_fd_flags(0) instead of get_unused_fd()
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@....com>
>
> 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.
BTW, thanks for the review and applying.
Regards.
--
Yann Droneaud
OPTEYA
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists