From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Artem B. Bityuckiy" Subject: Re: 2.6.12-rc4-mm1 Date: Wed, 18 May 2005 14:06:31 +0400 Message-ID: <1116410791.20667.5.camel@sauron.oktetlabs.ru> References: <20050512033100.017958f6.akpm@osdl.org> <4284BF66.1050704@friservices.com> <1116008021.23972.28.camel@hades.cambridge.redhat.com> <42854F34.2070806@friservices.com> Reply-To: dedekind@infradead.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-CzFTKvFuSueWhsl8evCJ" Cc: David Woodhouse , Andrew Morton , linux-fsdevel@vger.kernel.org Return-path: Received: from [213.170.72.194] ([213.170.72.194]:9946 "EHLO shelob.oktetlabs.ru") by vger.kernel.org with ESMTP id S262150AbVERKGl (ORCPT ); Wed, 18 May 2005 06:06:41 -0400 To: steve In-Reply-To: <42854F34.2070806@friservices.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org --=-CzFTKvFuSueWhsl8evCJ Content-Type: text/plain Content-Transfer-Encoding: 7bit Steve, > okay, reproduced after a couple hours of running (nothing intensive), > then doing a grep blah -r /* I can't reproduce your problem using 2.6.12-rc4 + the 2 patches. I created 50GB Reiserfs partition, copied a lot of data there (built linux sources in many exemplars) and issued 'grep -r blah *'. I also tried it with parallel writing to the partition - no help. I wonder, could you please try 2.6.12-rc4 + the 2 patches and see if the warning still there ? The above referred patches are (and they are also attached): ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12- rc4/2.6.12-rc4-mm1/broken-out/vfs-bugfix-two-read_inode-calles- without.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm1/broken-out/__wait_on_freeing_inode-fix.patch P.S. I wanted to try 2.6.12-rc4-mm2, but it OOPSes during the kernel load in my system. Then I switched to 2.6.12-rc4 in order not to fight with -mm2's problems. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. --=-CzFTKvFuSueWhsl8evCJ Content-Disposition: attachment; filename=vfs-bugfix-two-read_inode-calles-without.patch Content-Type: text/x-patch; name=vfs-bugfix-two-read_inode-calles-without.patch; charset=KOI8-R Content-Transfer-Encoding: 7bit diff -puN fs/inode.c~vfs-bugfix-two-read_inode-calles-without fs/inode.c --- 25/fs/inode.c~vfs-bugfix-two-read_inode-calles-without Fri May 6 15:12:47 2005 +++ 25-akpm/fs/inode.c Fri May 6 15:12:47 2005 @@ -282,6 +282,13 @@ static void dispose_list(struct list_hea if (inode->i_data.nrpages) truncate_inode_pages(&inode->i_data, 0); clear_inode(inode); + + spin_lock(&inode_lock); + hlist_del_init(&inode->i_hash); + list_del_init(&inode->i_sb_list); + spin_unlock(&inode_lock); + + wake_up_inode(inode); destroy_inode(inode); nr_disposed++; } @@ -317,8 +324,6 @@ static int invalidate_list(struct list_h inode = list_entry(tmp, struct inode, i_sb_list); invalidate_inode_buffers(inode); if (!atomic_read(&inode->i_count)) { - hlist_del_init(&inode->i_hash); - list_del(&inode->i_sb_list); list_move(&inode->i_list, dispose); inode->i_state |= I_FREEING; count++; @@ -439,8 +444,6 @@ static void prune_icache(int nr_to_scan) if (!can_unuse(inode)) continue; } - hlist_del_init(&inode->i_hash); - list_del_init(&inode->i_sb_list); list_move(&inode->i_list, &freeable); inode->i_state |= I_FREEING; nr_pruned++; --=-CzFTKvFuSueWhsl8evCJ Content-Disposition: attachment; filename=__wait_on_freeing_inode-fix.patch Content-Type: text/x-patch; name=__wait_on_freeing_inode-fix.patch; charset=KOI8-R Content-Transfer-Encoding: 7bit diff -puN fs/inode.c~__wait_on_freeing_inode-fix fs/inode.c --- 25/fs/inode.c~__wait_on_freeing_inode-fix 2005-05-09 20:09:33.000000000 -0700 +++ 25-akpm/fs/inode.c 2005-05-09 20:09:33.000000000 -0700 @@ -1241,29 +1241,21 @@ int inode_wait(void *word) } /* - * If we try to find an inode in the inode hash while it is being deleted, we - * have to wait until the filesystem completes its deletion before reporting - * that it isn't found. This is because iget will immediately call - * ->read_inode, and we want to be sure that evidence of the deletion is found - * by ->read_inode. + * If we try to find an inode in the inode hash while it is being + * deleted, we have to wait until the filesystem completes its + * deletion before reporting that it isn't found. This function waits + * until the deletion _might_ have completed. Callers are responsible + * to recheck inode state. + * + * It doesn't matter if I_LOCK is not set initially, a call to + * wake_up_inode() after removing from the hash list will DTRT. + * * This is called with inode_lock held. */ static void __wait_on_freeing_inode(struct inode *inode) { wait_queue_head_t *wq; DEFINE_WAIT_BIT(wait, &inode->i_state, __I_LOCK); - - /* - * I_FREEING and I_CLEAR are cleared in process context under - * inode_lock, so we have to give the tasks who would clear them - * a chance to run and acquire inode_lock. - */ - if (!(inode->i_state & I_LOCK)) { - spin_unlock(&inode_lock); - yield(); - spin_lock(&inode_lock); - return; - } wq = bit_waitqueue(&inode->i_state, __I_LOCK); prepare_to_wait(wq, &wait.wait, TASK_UNINTERRUPTIBLE); spin_unlock(&inode_lock); --=-CzFTKvFuSueWhsl8evCJ--