From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [git pull] vfs pile 1 Date: Mon, 9 Jan 2012 00:25:26 +0000 Message-ID: <20120109002526.GS23916@ZenIV.linux.org.uk> References: <20120105022318.GG23916@ZenIV.linux.org.uk> <20120108235039.GQ23916@ZenIV.linux.org.uk> <20120108235338.GR23916@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Toshiyuki Okajima To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, Jan 08, 2012 at 04:11:17PM -0800, Linus Torvalds wrote: > On Sun, Jan 8, 2012 at 3:53 PM, Al Viro wrote: > > > > ... and sure enough, ext3 has the same piece of fun. > > Hmm. Do we want to have the s_remove_count games for this "temporarily > zero nlink" case? Maybe we don't want to do drop_nlink/set_nlink? Does > it matter? The thing is, the total result in case of failure should be drop_nlink with s_remove_count bumped. We could turn that into set i_nlink to 0, without touching s_remove_count write the body if failed, bump s_remove_count and bugger off otherwise set i_nlink to 1, without touching s_remove_count but that's far more intrusive change than what I posted. > Anyway, mind sending me a patch with changelog and sign-off? Sure, will do. I have several more fixes in my tree right now (including such gems as double kfree() in devpts on mount failure ;-/), so I'll send a pull request in a couple of hours anyway. Would you be OK with having that patch in the same pile?