On Fri 20-06-25 14:48:47, Sergey Senozhatsky wrote: > On (25/06/20 13:53), Sergey Senozhatsky wrote: > > On (25/05/26 23:12), Sergey Senozhatsky wrote: > [..] > > Surprisingly enough, this did not help. > > > > Jan, one more silly question: > > > > fsnotify_get_mark_safe() and fsnotify_put_mark_wake() can be called on > > NULL mark. Is it possible that between fsnotify_prepare_user_wait(iter_info) > > and fsnotify_finish_user_wait(iter_info) iter_info->marks[type] changes in > > such a way that creates imbalance? That is, fsnotify_finish_user_wait() sees > > more NULL marks and hence does not rollback all the group->user_waits > > increments that fsnotify_prepare_user_wait() did? > > No, that doesn't seem to be possible. Sorry for the noise. Yeah, iter_info is local and should not change outside of the call itself. > My another silly idea was, fsnotify_put_mark_wake() is called in a loop > and it tests group->shutdown locklessly, as far as I can tell, so maybe > there is a speculative load and we use stale/"cached" group->shutdown > value w/o ever waking up ->notification_waitq. Am running out of ideas. Well, but atomic_dec_and_test() in fsnotify_put_mark_wake() should be a full memory barrier so such reordering should not be possible? At least not on the CPU, you can check disassembly of fsnotify_put_mark_wake() on your kernel whether the fetch of group->shutdown indeed happens after the atomic_dec_and_test() (but it should because && is a sequencing point and thus a compiler barrier). Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
