search for: clear_inod

...ocfs2_inode_lock() ocfs2_query_inode_wipe() -> fail ocfs2_inode_unlock() ocfs2_dentry_post_unlock() ocfs2_drop_dentry_lock() iput() ocfs2_delete_inode() ocfs2_inode_lock() ocfs2_query_inode_wipe() -> fail ocfs2_inode_unlock() clear_inode() clear_inode() The question is how to avoid this. It seems to me that we have to really do open_lock() and not just trylock to avoid the race. Is there any reason why we cannot move the open_lock() before inode_lock() in ocfs2_delete_inode()? Honza -- Jan Kara <jack at...

...tual address 00000004 Aug 16 11:33:14 asc_server kernel: current->tss.cr3 = 06bab000, %cr3 = 06bab000 Aug 16 11:33:14 asc_server kernel: *pde = 00000000 Aug 16 11:33:14 asc_server kernel: Oops: 0002 Aug 16 11:33:14 asc_server kernel: CPU: 0 Aug 16 11:33:14 asc_server kernel: EIP: 0010:[fat_clear_inode+32/44] Aug 16 11:33:14 asc_server kernel: EFLAGS: 00010286 Aug 16 11:33:14 asc_server kernel: eax: 00000000 ebx: c5fe6220 ecx: c5fe6220 edx: 00000000 Aug 16 11:33:14 asc_server kernel: esi: c6697e1c edi: 00001005 ebp: c6697e1c esp: c6697d7c Aug 16 11:33:14 asc_server kernel: ds: 0018...

...4.3p6-aed/fs/coda/inode.c --- linux-2.4.3p6/fs/coda/inode.c Fri Mar 23 10:54:50 2001 +++ linux-2.4.3p6-aed/fs/coda/inode.c Fri Mar 23 10:57:05 2001 @@ -209,7 +209,7 @@ return; } - memset(cii, 0, sizeof(struct coda_inode_info)); + /* The inode->u struct is zeroed for us by clear_inode() */ list_add(&cii->c_cilist, &sbi->sbi_cihead); cii->c_magic = CODA_CNODE_MAGIC; } diff -ru linux-2.4.3p6/fs/ext2/ialloc.c linux-2.4.3p6-aed/fs/ext2/ialloc.c --- linux-2.4.3p6/fs/ext2/ialloc.c Fri Dec 8 18:35:54 2000 +++ linux-2.4.3p6-aed/fs/ext2/ialloc.c Fri Mar 23...

...rty+2e/a0> Trace; c012ae2d <generic_file_write+33d/780> Trace; c0130b83 <add_to_swap_cache+63/b0> Trace; c012db40 <do_ccupdate_local+0/40> Trace; c015060b <write_dquot+ab/100> Trace; c0150a50 <dqput+70/d0> Trace; c015196b <dquot_drop+3b/50> Trace; c014c03a <clear_inode+7a/100> Trace; c014b44f <destroy_inode+1f/30> Trace; c014c100 <dispose_list+40/60> Trace; c014c359 <prune_icache+b9/e0> Trace; c014c3a0 <shrink_icache_memory+20/40> Trace; c012fafe <shrink_caches+6e/90> Trace; c012fb5c <try_to_free_pages+3c/60> Trace; c01304c...

...race; c01de57f <scsi_io_completion+16f/850> Trace; c0138bb5 <free_pages+535/27c0> Trace; f88bf0c9 <[ext3]ext3_file_write+39/d0> Trace; c015e991 <seq_printf+f01/a9c0> Trace; c015ee7c <seq_printf+13ec/a9c0> Trace; c015ff11 <seq_printf+2481/a9c0> Trace; c01586ce <clear_inode+8e/260> Trace; c01587ac <clear_inode+16c/260> Trace; c0156590 <dput+30/190> Trace; c0158a42 <invalidate_device+102/240> Trace; c0158af4 <invalidate_device+1b4/240> Trace; c0137323 <kmem_find_general_cachep+1583/24b0> Trace; c0137386 <kmem_find_general_cachep+15e...

...ebug printks anymore Index: src/super.c =================================================================== --- src/super.c (revision 1426) +++ src/super.c (working copy) @@ -196,9 +196,7 @@ static struct super_operations ocfs_sops = { .statfs = ocfs_statfs, - .put_inode = ocfs_put_inode, .clear_inode = ocfs_clear_inode, - //put_inode = force_delete, .delete_inode = ocfs_delete_inode, .sync_fs = ocfs_sync_fs, .write_super = ocfs_write_super, Index: src/inode.c =================================================================== --- src/inode.c (revision 1426) +++ src/inod...

...ksyms together with a manual > lookup of the call trace: > > process umount > EIP c01190b8 (set_running_and_schedule) > call trace: > c01144c9 f25f9ec0 IO_APIC_get_PCI_irq_vector > c010a8b0 f25f9ed0 enable_irq > c014200c f25f9ef0 fsync_buffers_list > c0155595 f25f9efc clear_inode > c015553d f25f9f2c invalidate_inodes > c01461d8 f25f9f78 get_super > c014a629 f25f9f94 path_release > c0157c58 f25f9fc0 sys_umount > c0108cab sys_sigaltstack > > > attached /proc/ksyms | sort > <<ksyms>> > Any idea what can cause this ? > >...

...Took > some more time but finally it roared its ugly head. > > This is the stack trace from the new kernel: > > > c01190b8 f3791eb4 set_running_and_schedule > > c010a8b0 f3791ed0 enable_irq > > c014200c f3791f0c IO_APIC_get_PCI_irq_vector > > c0155595 f3791f0c clear_inode > > c01556639 f3791f60 invalidate_inodes > > c0149629 f3791f8 set_binfmt > > c0157c58 f3791f94 sys_umount > > c0108cab 0f3791fc0 sys_sigaltstack > > > Andrew Morton suggested a buffer.c patch for reducing search > complexity, which I will try next. > &g...

This patch plugs a race between the downconvert thread and an unlock ast message. Specifically, after the downconvert worker has done its task, the dc thread needs to check whether an unlock ast made the downconvert moot. Reported-by: David Teigland <teigland at redhat.com> Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com> Acked-by: Mark Fasheh <mfasheh at sus.com> ---

Hello Andrew, I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/ and I have a big problem with: once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs. I tested it on 50-60 servers and it is the same problem. I tested kernel 2.4.20 without your patch: no problem. # uname -a Linux XXXXXX

...[last unloaded: scsi_wait_scan] Dec 2 19:46:50 hn-r410-openvz01 kernel: [ 9903.038545] Pid: 48, comm: kswapd1 Not tainted 2.6.32-bpo.5-openvz-amd64 #1 feoktistov PowerEdge R410 Dec 2 19:46:50 hn-r410-openvz01 kernel: [ 9903.038602] RIP: 0010:[<ffffffff81102ade>] [<ffffffff81102ade>] clear_inode+0x1b/0xd0 Dec 2 19:46:50 hn-r410-openvz01 kernel: [ 9903.038665] RSP: 0018:ffff88083c919c30 EFLAGS: 00010202 Dec 2 19:46:50 hn-r410-openvz01 kernel: [ 9903.038697] RAX: 0000000000000000 RBX: ffff8805d8f9b000 RCX: ffff88083c919c90 Dec 2 19:46:50 hn-r410-openvz01 kernel: [ 9903.038734] RDX: 0000...

...[<ffffffff8832dd66>] :xfs:xfs_validate_fields+0x24/0x4b Sep 7 21:08:19 backup kernel: [<ffffffff8832e361>] :xfs:xfs_vn_unlink+0x3d/0x4f Sep 7 21:08:19 backup kernel: [<ffffffff80063bb7>] mutex_lock+0xd/0x1d Sep 7 21:08:19 backup kernel: [<ffffffff883308fc>] :xfs:xfs_fs_clear_inode+0xa5/0xec Sep 7 21:08:19 backup kernel: [<ffffffff80022861>] clear_inode+0xd2/0x123 Sep 7 21:08:19 backup kernel: [<ffffffff8002f19a>] generic_delete_inode+0xde/0x143 Sep 7 21:08:19 backup kernel: [<ffffffff8003c1f6>] do_unlinkat+0xd5/0x141 Sep 7 21:08:19 backup kernel: [...

...an_block_rsv->count)) { + rsv = root->orphan_block_rsv; + root->orphan_block_rsv = NULL; + } else { + rsv = NULL; + } + spin_unlock(&root->orphan_lock); + + if (rsv) { + WARN_ON(rsv->size > 0); + btrfs_free_block_rsv(root, rsv); + } + btrfs_remove_delayed_node(inode); clear_inode(inode); return; @@ -7650,7 +7673,6 @@ static int btrfs_truncate(struct inode *inode) } if (ret == 0 && inode->i_nlink > 0) { - trans->block_rsv = root->orphan_block_rsv; ret = btrfs_orphan_del(trans, inode); if (ret) err = ret; -- 1.7.9.5 -- To unsubscribe...

Hi all, I was intending on trying out gjournal on a new disk i've added in my desktop. I had a look to see what the most recent patch provided by Pawel and found http://people.freebsd.org/~pjd/patches/gjournal6_20061024.patch I created the directories as per Pawel's original post (http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html) and the patch succeeded with no failed