Re: [RFC PATCH] vfs: avoid creation of inode number 0 in get_next_ino

[Rik van Riel <riel@redhat.com>]

On 06/25/2015 11:25 AM, Carlos Maiolino wrote:
> currently, get_next_ino() is able to create inodes with inode number = 0.
> This have a bad impact in the filesystems relying in this function to generate
> inode numbers.
> 
> While there is no problem at all in having inodes with number 0, userspace tools
> which handle file management tasks can have problems handling these files, like
> for example, the impossiblity of users to delete these files, since glibc will
> ignore them. So, I believe the best way is kernel to avoid creating them.
> 
> This problem has been raised previously, but the old thread didn't have any
> other update for a year+, and I've seen too many users hitting the same issue
> regarding the impossibility to delete files while using filesystems relying on
> this function. So, I'm starting the thread again, with the same patch
> that I believe is enough to address this problem.
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>

This approach makes a lot of sense to me. A very simple
change in the kernel helps userspace avoid a world of pain.

> diff --git a/fs/inode.c b/fs/inode.c
> index ea37cd1..01c3a4a 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -839,7 +839,11 @@ unsigned int get_next_ino(void)
>  	}
>  #endif
>  
> -	*p = ++res;
> +	res++;
> +	/* get_next_ino should not provide a 0 inode number */

Would be nice if the comment explained why. Maybe something like this?

	/*
	 * Glibc is unable to delete inode zero, which can cause all
	 * kinds of havoc for userspace. That trouble is easily avoided
	 * by never returning an inode number of zero.
	 */

> +	if (unlikely(!res))
> +		res++;
> +	*p = res;
>  	put_cpu_var(last_ino);
>  	return res;
>  }
> 


-- 
All rights reversed