[RFC] vfs: avoid creation of inode number 0 in get_next_ino
diff mbox

Message ID 1435245958-4507-1-git-send-email-cmaiolino@redhat.com
State New
Headers show

Commit Message

Carlos Maiolino June 25, 2015, 3:25 p.m. UTC
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>
---
 fs/inode.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Rik van Riel June 30, 2015, 4:35 a.m. UTC | #1
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;
>  }
>

Patch
diff mbox

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 */
+	if (unlikely(!res))
+		res++;
+	*p = res;
 	put_cpu_var(last_ino);
 	return res;
 }