Re: [PATCH 02/13] ppc/cell: use get_unused_fd_flags(0) instead ofget_unused_fd()

[Benjamin Herrenschmidt]

On Tue, 2013-07-02 at 18:39 +0200, Yann Droneaud wrote:
> Macro get_unused_fd() is used to allocate a file descriptor with
> default flags. Those default flags (0) can be "unsafe":
> O_CLOEXEC must be used by default to not leak file descriptor
> across exec().
> 
> Instead of macro get_unused_fd(), functions anon_inode_getfd()
> or get_unused_fd_flags() should be used with flags given by userspace.
> If not possible, flags should be set to O_CLOEXEC to provide userspace
> with a default safe behavor.
> 
> In a further patch, get_unused_fd() will be removed so that
> new code start using anon_inode_getfd() or get_unused_fd_flags()
> with correct flags.
> 
> This patch replaces calls to get_unused_fd() with equivalent call to
> get_unused_fd_flags(0) to preserve current behavor for existing code.
> 
> The hard coded flag value (0) should be reviewed on a per-subsystem basis,
> and, if possible, set to O_CLOEXEC.
> 
> Signed-off-by: Yann Droneaud <ydroneaud@xxxxxxxxxx>

Should I merge this (v5 on patchwork) or let Al do it ?

Acked-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>

> ---
>  arch/powerpc/platforms/cell/spufs/inode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
> index f390042..88df441 100644
> --- a/arch/powerpc/platforms/cell/spufs/inode.c
> +++ b/arch/powerpc/platforms/cell/spufs/inode.c
> @@ -301,7 +301,7 @@ static int spufs_context_open(struct path *path)
>  	int ret;
>  	struct file *filp;
>  
> -	ret = get_unused_fd();
> +	ret = get_unused_fd_flags(0);
>  	if (ret < 0)
>  		return ret;
>  
> @@ -518,7 +518,7 @@ static int spufs_gang_open(struct path *path)
>  	int ret;
>  	struct file *filp;
>  
> -	ret = get_unused_fd();
> +	ret = get_unused_fd_flags(0);
>  	if (ret < 0)
>  		return ret;
>  


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