Michal Hocko wrote: > On Tue 20-03-18 21:52:33, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > A single stack trace in the changelog would be sufficient IMHO. > > > Appart from that. What do you expect users will do about this trace? > > > Sure they will see a path which holds mmap_sem, we will see a bug report > > > but we can hardly do anything about that. We simply cannot drop the lock > > > from that path in 99% of situations. So _why_ do we want to add more > > > information to the log? > > > > This case is blocked at i_mmap_lock_write(). > > But why does i_mmap_lock_write matter for oom_reaping. We are not > touching hugetlb mappings. dup_mmap holds mmap_sem for write which is > the most probable source of the backoff. If i_mmap_lock_write can bail out upon SIGKILL, the OOM victim will be able to release mmap_sem held for write, which helps the OOM reaper not to back off.
