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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
