On Wed, Apr 09, 2025 at 03:14:44PM +0200, Sebastian Andrzej Siewior wrote: > One question: Do we need this lazy/ MNT_DETACH case? Couldn't we handle > them all via queue_rcu_work()? > If so, couldn't we have make deferred_free_mounts global and have two > release_list, say release_list and release_list_next_gp? The first one > will be used if queue_rcu_work() returns true, otherwise the second. > Then once defer_free_mounts() is done and release_list_next_gp not > empty, it would move release_list_next_gp -> release_list and invoke > queue_rcu_work(). > This would avoid the kmalloc, synchronize_rcu_expedited() and the > special-sauce. > To my understanding it was preferred for non-lazy unmount consumers to wait until the mntput before returning. That aside if I understood your approach it would de facto serialize all of these? As in with the posted patches you can have different worker threads progress in parallel as they all get a private list to iterate. With your proposal only one can do any work. One has to assume with sufficient mount/unmount traffic this can eventually get into trouble.
