From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [RFC PATCH] vfs: avoid creation of inode number 0 in get_next_ino Date: Tue, 30 Jun 2015 00:35:42 -0400 Message-ID: <55921C9E.90405@redhat.com> References: <1435245958-4507-1-git-send-email-cmaiolino@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Carlos Maiolino , linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51893 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750733AbbF3Efs (ORCPT ); Tue, 30 Jun 2015 00:35:48 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 2278E2ED155 for ; Tue, 30 Jun 2015 04:35:48 +0000 (UTC) In-Reply-To: <1435245958-4507-1-git-send-email-cmaiolino@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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