On Wed, May 09, 2012 at 05:55:57PM +1000, Nick Piggin wrote: > On 8 May 2012 11:07, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> writes: [ . . . ] > >> 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. > > No, because that's not the only requirement for the rcu_barrier. > > Making it asynchronous is not something I wanted to do, because > then we potentially have a process exiting from kernel space after > releasing last reference on a mount, but the mount does not go > away until "some time" later. Which is crazy. In any case, I am looking into making concurrent calls to rcu_barrier() share each others' work, so if asynchronous turns out to be needed, it will be efficient. Thanx, Paul > However. We are holding vfsmount_lock for read at the point > where we ever actually do anything with an "rcu-referenced" > dentry/inode. I wonder if we could use this to get i_sb pinned. > -- 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
