From patchwork Thu Jun 25 20:58:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos Maiolino X-Patchwork-Id: 6677471 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7DF89C05AC for ; Thu, 25 Jun 2015 20:58:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BA07920702 for ; Thu, 25 Jun 2015 20:58:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DFC52203F3 for ; Thu, 25 Jun 2015 20:58:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751655AbbFYU6x (ORCPT ); Thu, 25 Jun 2015 16:58:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43154 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751575AbbFYU6x (ORCPT ); Thu, 25 Jun 2015 16:58:53 -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 EB01D83F7E; Thu, 25 Jun 2015 20:58:52 +0000 (UTC) Received: from hades.maiolino.org.com ([10.3.112.5]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5PKwnX1024353; Thu, 25 Jun 2015 16:58:50 -0400 From: Carlos Maiolino To: linux-fsdevel@vger.kernel.org, lkml@vger.kernel.org Subject: [PATCH] vfs: avoid creation of inode number 0 in get_next_ino V2 Date: Thu, 25 Jun 2015 17:58:41 -0300 Message-Id: <1435265921-21652-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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; }