From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:52796 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752453AbbLEX4Q (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sat, 5 Dec 2015 18:56:16 -0500
Date: Sat, 5 Dec 2015 23:56:12 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Boaz Harrosh <ooo@electrozaur.com>
Cc: osd-dev@open-osd.org, linux-fsdevel@vger.kernel.org
Subject: [RFC][exofs] locking for sbi->s_nextid?
Message-ID: <20151205235612.GC20997@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

	Looks like exofs_new_inode() does this

        inode->i_ino = sbi->s_nextid++;

without any locking; sure, the parent directory is locked, but that's not
worth much on a filesystem that supports mkdir()...  Am I missing something
subtle here?  Another question in the code nearby:

        ret = ore_get_io_state(&sbi->layout, &oi->oc, &ios);
        if (unlikely(ret)) {
                EXOFS_ERR("exofs_new_inode: ore_get_io_state failed\n");
                return ERR_PTR(ret);
        }

aren't we leaking a struct inode here?  Path around ore_create() is
also interesting - looks like its failure causes a leak (at least if
it happens early on)...