From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: invalidate_inode_buffers call in invalidate_list? Date: Mon, 18 Oct 2010 12:11:50 +1100 Message-ID: <20101018011150.GI29677@dastard> References: <20101017233900.GA1525@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from bld-mail18.adl2.internode.on.net ([150.101.137.103]:53979 "EHLO mail.internode.on.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751131Ab0JRBLx (ORCPT ); Sun, 17 Oct 2010 21:11:53 -0400 Content-Disposition: inline In-Reply-To: <20101017233900.GA1525@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Oct 17, 2010 at 07:39:00PM -0400, Christoph Hellwig wrote: > Does anyone remember why we call invalidate_inode_buffers in > invalidate_list? These days we basically call invalidate_inode_buffers > only in ->evict_inode, which we will call from invalidate_list in > case of a zero refcount. > > For calls to invalidate_inode_buffers it's hamrless, but for other > callers it means we lose track of which buffers were dirtied for > an inode, and thus can write them out during fsync. > > Something like the untested patch below should fix it. Seems reasonable to me. I can't see any obvious reason why the call in evict_inode in not sufficient to ensure the inode is correctly cleaned up, and none of the inode buffers take a reference to the inode so they shouldn't need to be invalidated to get the reference count to zero.... > While we're > at it - any reaso not to consider I_NEW inodes as busy in > invalidate_list? Not that I can think of. I'd probably leave the WARN_ON() condition there, though, so that if we do ever encounter them we hear about it... Cheers, Dave. -- Dave Chinner david@fromorbit.com