From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] ext3 [linux-2.6.2.]: accessing already freed inodes when under memory pressure Date: Thu, 19 Feb 2004 10:49:05 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040219104905.7d87f351.akpm@osdl.org> References: <200402191321.39592.cotte@freenet.de> <1077212393.2070.571.camel@sisko.scot.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: torvalds@osdl.org, cotte@freenet.de, linux-fsdevel@vger.kernel.org, schwidefsky@de.ibm.com, cotte@de.ibm.com, sct@redhat.com Return-path: Received: from fw.osdl.org ([65.172.181.6]:53215 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S267479AbUBSStJ (ORCPT ); Thu, 19 Feb 2004 13:49:09 -0500 To: "Stephen C. Tweedie" In-Reply-To: <1077212393.2070.571.camel@sisko.scot.redhat.com> List-Id: linux-fsdevel.vger.kernel.org "Stephen C. Tweedie" wrote: > > At the end of ext3_truncate(), we do: > > if (inode->i_nlink) > ext3_orphan_del(handle, inode); This bug seems to only manifest on s390, which makes me suspect it is a race. Because s390's I think tend to have wider race windows at times. (But no reports from NUMAQ, which also has wide windows...) I wonder about the i_nlink locking. Perhaps we lack some, and we are accidentally leaving indoes on the orphan list. There are a lot of places where we don't actually hold inode->i_sem while diddling inode->i_nlink: ext3_unlink, ext3_rename, others. hmm, I wonder if that could be it? If the inode is hardlinked into a different directory then the parent dir's i_sem gives us no i_nlink protection. Carsten, are you aware of a particular workload which triggers this?