"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> writes: > On Mon, May 07, 2012 at 11:17:06PM +0100, Al Viro wrote: >> On Mon, May 07, 2012 at 02:51:08PM -0700, Eric W. Biederman wrote: >> >> > /proc and similar non-modular filesystems do not need a rcu_barrier >> > in deactivate_locked_super. Being non-modular there is no danger >> > of the rcu callback running after the module is unloaded. >> >> There's more than just a module unload there, though - actual freeing >> struct super_block also happens past that rcu_barrier()... Al. I have not closely audited the entire code path but at a quick sample I see no evidence that anything depends on inode->i_sb being rcu safe. Do you know of any such location? It has only been a year and a half since Nick added this code which isn't very much time to have grown strange dependencies like that. > Is there anything in there for which synchronous operation is required? > If not, one approach would be to drop the rcu_barrier() calls to a > workqueue or something similar. We need to drain all of the rcu callbacks before we free the slab and unload the module. This actually makes deactivate_locked_super the totally wrong place for the rcu_barrier. We want the rcu_barrier in the module exit routine where we destroy the inode cache. What I see as the real need is the filesystem modules need to do: rcu_barrier() kmem_cache_destroy(cache); Perhaps we can add some helpers to make it easy. But I think I would be happy today with simply moving the rcu_barrier into every filesystems module exit path, just before the file system module destoryed it's inode cache. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
