All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2
@ 2015-06-25 20:58 Carlos Maiolino
  2015-07-06 17:15 ` Rik van Riel
  0 siblings, 1 reply; 2+ messages in thread
From: Carlos Maiolino @ 2015-06-25 20:58 UTC (permalink / raw)
  To: linux-fsdevel, lkml

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.

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 changes in the patch
suggested by Viro.

Changelog:

	V2: Use do..while() instead of unlikely(!res)

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
---
 fs/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index ea37cd1..85a05b7 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -839,7 +839,9 @@ unsigned int get_next_ino(void)
 	}
 #endif
 
-	*p = ++res;
+	do {
+		*p = ++res;
+	} while (!res);
 	put_cpu_var(last_ino);
 	return res;
 }
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2
  2015-06-25 20:58 [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2 Carlos Maiolino
@ 2015-07-06 17:15 ` Rik van Riel
  0 siblings, 0 replies; 2+ messages in thread
From: Rik van Riel @ 2015-07-06 17:15 UTC (permalink / raw)
  To: Carlos Maiolino, linux-fsdevel, lkml

On 06/25/2015 04:58 PM, 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.
> 
> 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 changes in the patch
> suggested by Viro.
> 
> Changelog:
> 
> 	V2: Use do..while() instead of unlikely(!res)
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-07-06 17:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-25 20:58 [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2 Carlos Maiolino
2015-07-06 17:15 ` Rik van Riel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.