On 30/4/24 21:25, Lucas Karpinski wrote:
On Fri, Apr 26, 2024 at 09:09:41PM +0100, Al Viro wrote:
+ call_rcu(&drelease->rcu, delayed_mount_release);
... which is a bad idea, since call_rcu() callbacks are run
from interrupt context. Which makes blocking in them a problem.
Thanks for the quick review.
Documentation/RCU/checklist.rst suggests switching to queue_rcu_work()
function in scenarios where the callback function can block. This seems
like it would fix the issue you found, while still providing similar
performance improvements.
You know I've been looking at this and you can see that mntput() will
just call
mntput_no_expire() which queues work to do the bulk of the work and returns.
So I'm wondering what would happen to the timing if you simply didn't
call the
rcu wait for the lazy umount case and left everything else as it is.
Ian
