--Mika
Dave Peterson wrote:
>I think I found a race condition in some of the inode handling
>code. Here's where I think it is:
>
> 1. Task A is inside kill_super(). It clears the MS_ACTIVE
> flag of the s_flags field of the super_block struct and
> calls invalidate_inodes(). In invalidate_inodes(), it
> attempts to acquire inode_lock and spins because task B,
> executing inside iput(), just decremented the reference
> count of some inode i to 0 and acquired inode_lock.
>
> 2. Then the "if (!inode->i_nlink)" test condition evaluates
> to false for task B so it executes the following chunk
> of code:
>
> 01 } else {
> 02 if (!list_empty(&inode->i_hash)) {
> 03 if (!(inode->i_state & (I_DIRTY|I_LOCK))) {
> 04 list_del(&inode->i_list);
> 05 list_add(&inode->i_list, &inode_unused);
> 06 }
> 07 inodes_stat.nr_unused++;
> 08 spin_unlock(&inode_lock);
> 09 if (!sb || (sb->s_flags & MS_ACTIVE))
> 10 return;
> 11 write_inode_now(inode, 1);
> 12 spin_lock(&inode_lock);
> 13 inodes_stat.nr_unused--;
> 14 list_del_init(&inode->i_hash);
> 15 }
> 16 list_del_init(&inode->i_list);
> 17 inode->i_state|=I_FREEING;
> 18 inodes_stat.nr_inodes--;
> 19 spin_unlock(&inode_lock);
> 20 if (inode->i_data.nrpages)
> 21 truncate_inode_pages(&inode->i_data, 0);
> 22 clear_inode(inode);
> 23 }
> 24 destroy_inode(inode);
>
> Now the test condition on line 02 evaluates to true, so
> task B adds the inode to the inode_unused list and then
> releases inode_lock on line 08.
>
> 3. Now A acquires inode_lock and B spins on inode_lock inside
> write_inode_now();
>
> 4. Task A calls invalidate_list(), transferring inode i from
> the inode_unused list to its own private throw_away list.
>
> 5. Task A releases inode_lock, allowing B to acquire inode_lock
> and continue executing.
>
> 6. A attempts to destroy inode i inside dispose_list() while B
> simultaneously attempts to destroy i, potentially causing
> all sorts of bad things to happen.
>
>So, did I find a bug or are my eyes playing tricks on me?
>
>-Dave Peterson
> dsp@llnl.gov
>
>P.S. Please CC my email address when responding to this message.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/