From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2 Date: Mon, 06 Jul 2015 13:15:23 -0400 Message-ID: <559AB7AB.2020205@redhat.com> References: <1435265921-21652-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, lkml@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52827 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754829AbbGFRPa (ORCPT ); Mon, 6 Jul 2015 13:15:30 -0400 In-Reply-To: <1435265921-21652-1-git-send-email-cmaiolino@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 Reviewed-by: Rik van Riel -- All rights reversed