From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: NULL inode->i_mapping in generic_sync_sb_inodes Date: Wed, 07 Oct 2009 09:15:47 -0400 Message-ID: References: <4ACC9E8A0200008A000439B0@novprvlin0050.provo.novell.com> <20091007124327.GT30316@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nick Piggin , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nick Piggin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:5069 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933457AbZJGNQW (ORCPT ); Wed, 7 Oct 2009 09:16:22 -0400 In-Reply-To: <20091007124327.GT30316@wotan.suse.de> (Nick Piggin's message of "Wed, 7 Oct 2009 14:43:27 +0200") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin writes: >> hch mentioned that it would be good to instrument to what file system >> the inode belonged. Anything else you'd like to look at? > > Not too sure. I guess i_state. Maybe you could take s_umount lock > and see if it is still mounted? > > Actually most useful will be to find all places where i_mapping is > set to NULL, and record in the inode some callchain for the last > site which set i_mapping to NULL. Dump this stack when you hit the > bug. Well, I can't find a single place where i_mapping is set to NULL. ;-) I'll see what I can dig up. Cheers, Jeff