Messages in this thread |  | | Date | Tue, 05 Dec 2000 00:25:13 +1100 | From | Andrew Morton <> | Subject | Re: [PATCH] inode dirty blocks Re: test12-pre4 |
| |
Alexander Viro wrote: > > On Sun, 3 Dec 2000, Linus Torvalds wrote: > > > > > Synching up with Alan and various other stuff. The most important one > > being the fix to the inode dirty block list. > > It doesn't solve the problem. If you unlink a file with dirty metadata > you have a nice chance to hit the BUG() in inode.c:83. I hope that patch > below closes all remaining holes. See analysis in previous posting > (basically, bforget() is not enough when we free the block; bh should > be removed from the inode's list regardless of the ->b_count).
It's still happening.
The good news is that I have a machine which does it within 15-30 minutes. The only interesting difference is that is has 64 megs of RAM (all the others are 256) and its IDE system is a lot slower.
I removed the UnlockPage() at line 623 of vmscan.c because that's causing assertion failures at swap.c:271.
I changed destroy_inode() thusly:
static void destroy_inode(struct inode *inode) { if (!list_empty(&inode->i_dirty_buffers)) { struct task_struct *tsk;
printk("&inode->i_dirty_buffers=0x%p\n", &inode->i_dirty_buffers); printk("next=0x%p\n", inode->i_dirty_buffers.next); printk("prev=0x%p\n", inode->i_dirty_buffers.prev);
read_lock(&tasklist_lock); for_each_task(tsk) { printk("[%s]\n", tsk->comm); show_stack(tsk->thread.esp); printk("\n\n"); } read_unlock(&tasklist_lock);
BUG(); } kmem_cache_free(inode_cachep, (inode)); }
So we get a full task dump. Otherwise this is vanilla test12-pre4 plus your bforget_inode() patch. SMP kernel on UP hardware, so this is a good snapshot of system state.
First the BUG trace:
&inode->i_dirty_buffers=0xc1cc6c98 next=0xc03e9a78 prev=0xc03e9a78
Trace; c021b8c5 <tvecs+5a3d/1a358> Trace; c021b9c2 <tvecs+5b3a/1a358> Trace; c0146a86 <iput+18e/194> Trace; c01451a6 <d_delete+66/ac> Trace; c013df5d <vfs_unlink+18d/1c0> Trace; c013e035 <sys_unlink+a5/118> Trace; c0108fdf <system_call+33/38>
That's the same as before. Now some other interesting tasks. The fourth dbench may be interesting? And look at what kswapd is doing.
[dbench] Trace; c012bf9b <wakeup_kswapd+b3/d0> Trace; c012cc9e <__alloc_pages+246/2f8> Trace; c012671c <generic_file_write+270/454> Trace; c0144589 <dput+19/174> Trace; c013092a <sys_write+8e/c4>
[dbench] Trace; c012bf9b <wakeup_kswapd+b3/d0> Trace; c012cc9e <__alloc_pages+246/2f8> Trace; c012671c <generic_file_write+270/454> Trace; c0144589 <dput+19/174> Trace; c013092a <sys_write+8e/c4>
[dbench] Trace; c01c1557 <vgacon_cursor+1df/1e8> Trace; c018a34e <set_cursor+6e/80> Trace; c0118851 <printk+1a1/1b0> Trace; c0118851 <printk+1a1/1b0> Trace; c4800000 <_end+44e2e4c/10503eac> Trace; c0109324 <show_stack+d4/e8> Trace; c020c2c3 <stext_lock+759f/843c> Trace; c020c2c3 <stext_lock+759f/843c> Trace; c0145875 <destroy_inode+75/c4> Trace; c021b9b9 <tvecs+5b31/1a358> Trace; c0146a86 <iput+18e/194> Trace; c01451a6 <d_delete+66/ac> Trace; c013df5d <vfs_unlink+18d/1c0> Trace; c010002b <startup_32+2b/cb>
(This is `current')
[dbench] Trace; c01317fd <__wait_on_buffer+4d/e0> Trace; c0132cd9 <bread+45/70> Trace; c0156d6c <ext2_read_inode+104/3ec> Trace; c01465a8 <get_new_inode+cc/178> Trace; c014685d <iget4+f5/100>
[kupdate] Trace; c01156ea <schedule_timeout+7a/9c> Trace; c0115614 <process_timeout+0/5c> Trace; c0135304 <kupdate+a4/110> Trace; c01074c3 <kernel_thread+23/30>
[bdflush] Trace; c0135255 <bdflush+135/140> Trace; c01074c3 <kernel_thread+23/30>
[kreclaimd] Trace; c0116209 <interruptible_sleep_on+4d/80> Trace; c012c03f <kreclaimd+5b/dc> Trace; c0105000 <empty_bad_page+0/1000> Trace; c01074c3 <kernel_thread+23/30>
[kswapd] Trace; c01317fd <__wait_on_buffer+4d/e0> Trace; c0132cd9 <bread+45/70> Trace; c0157180 <ext2_update_inode+12c/408> Trace; c015748e <ext2_write_inode+32/6c> Trace; c0145d59 <sync_all_inodes+11d/168> Trace; c0146221 <prune_icache+31/124> Trace; c0146335 <shrink_icache_memory+21/30> Trace; c012bd3b <do_try_to_free_pages+5b/88> Trace; c0217b71 <tvecs+1ce9/1a358> Trace; c012bdf6 <kswapd+8e/180> Trace; c0105000 <empty_bad_page+0/1000> Trace; c01074c3 <kernel_thread+23/30> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |