Re: [PATCH 16/21] fs: Protect inode->i_state with the inode->i_lock

[Al Viro]

On Fri, Oct 22, 2010 at 11:37:05AM +0100, Al Viro wrote:

> What I'm going to do is to put together a branch with essentially cleanups
> and trivial fixes, with both patchsets forked off its tip.  Then move stuff
> to common stem, rediffing the branches as we go.  Then see what's left.

OK, the current (partial) set is in

git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ #merge-stem

What remains to be done (I'm about to fall down right now, so that'll have
to wait until tomorrow):

	* writeback_sb_inode() told to ignore I_FREEING ones in addition to
I_NEW and I_WILL_FREE ones it ignores now.  Currently I_FREEING can't be
found there at all, so that'll change nothing.
	* invalidate_inodes() - collect I_FREEING/I_WILL_FREE on a separate
list, then (after we'd evicted the stuff we'd decided to evict) wait until
they get freed by whatever's freeing them already.
	* remove_dquot_ref() - looks like we might be OK with that one being
as it is - it walks sb list of inodes and for things like prune_icache()
the inodes stay on said list all the way through evict(), so it either
doesn't care or it's already broken.  And no, I'm not discounting either
possibility - it needs further analysis.

That's it - after that we'll be OK with dropping and regaining inode_lock
between the moment when we set I_FREEING and removals from the lists.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/