On Fri, Feb 21, 2020 at 5:33 PM David Howells <dhowells@xxxxxxxxxx> wrote: > Jann Horn <jannh@xxxxxxxxxx> wrote: > > > (And as in the other case, the s->s_count increment will probably have > > to be moved above the add_watch_to_object(), unless you hold the > > sb_lock around it?) > > It shouldn't matter as I'm holding s->s_umount across the add and increment. > That prevents the watch from being removed: watch_sb() would have to get the > lock first to do that. It also deactivate_locked_super() from removing all > the watchers. Can't the same thing I already pointed out on "[PATCH 13/19] vfs: Add a mount-notification facility [ver #16]" also happen here? If another thread concurrently runs close(watch_fd) before the spin_lock(&sb_lock), pipe_release -> put_pipe_info -> free_pipe_info -> watch_queue_clear will run, correct? And then watch_queue_clear() will find the watch that we've just created and call its ->release_watch() handler, which causes put_super(), potentially dropping the refcount to zero? And then stuff will blow up. > I can move it before, but I probably have to drop s_umount before I can call > put_super().
