From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Roemen Subject: Re: 2.6.12-rc4-mm1 Date: Wed, 18 May 2005 11:16:54 -0500 Message-ID: <428B6A76.9000708@friservices.com> References: <20050512033100.017958f6.akpm@osdl.org> <4284BF66.1050704@friservices.com> <1116008021.23972.28.camel@hades.cambridge.redhat.com> <42854F34.2070806@friservices.com> <1116410791.20667.5.camel@sauron.oktetlabs.ru> Reply-To: steve@friservices.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060600080800060709020202" Cc: David Woodhouse , Andrew Morton , linux-fsdevel@vger.kernel.org Return-path: Received: from smtp-server.carlislefsp.com ([12.28.84.26]:10635 "EHLO imail.carlislefsp.com") by vger.kernel.org with ESMTP id S262281AbVERQRE (ORCPT ); Wed, 18 May 2005 12:17:04 -0400 To: dedekind@infradead.org In-Reply-To: <1116410791.20667.5.camel@sauron.oktetlabs.ru> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org This is a multi-part message in MIME format. --------------060600080800060709020202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit on 05/18/05 05:06 Artem B. Bityuckiy wrote the following: >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. > > > >------------------------------------------------------------------------ > >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++; > > > >------------------------------------------------------------------------ > >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); > > > okay, recompiled with those two files back in, and after an hour of running, while doing a tar -xjvf linux-2.6.11.tar.bz2, it kicks out that error (attached). Steve --------------060600080800060709020202 Content-Type: text/plain; name="dmesg_output" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_output" BUG: atomic counter underflow at: [] reiserfs_clear_inode+0x81/0xb0 [] clear_inode+0xe4/0x130 [] dispose_list+0x70/0x130 [] prune_icache+0xbf/0x1b0 [] shrink_icache_memory+0x14/0x40 [] shrink_slab+0x159/0x1a0 [] balance_pgdat+0x2b7/0x3b0 [] kswapd+0xd2/0xf0 [] autoremove_wake_function+0x0/0x50 [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x50 [] kswapd+0x0/0xf0 [] kernel_thread_helper+0x5/0x18 --------------060600080800060709020202--