Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[Michal Hocko]

On Thu 07-12-17 13:22:30, David Rientjes wrote:
[...]
> > diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> > index 9c8847395b5e..da673ca66e7a 100644
> > --- a/include/linux/sched/coredump.h
> > +++ b/include/linux/sched/coredump.h
> > @@ -68,8 +68,9 @@ static inline int get_dumpable(struct mm_struct *mm)
> >  #define MMF_RECALC_UPROBES	20	/* MMF_HAS_UPROBES can be wrong */
> >  #define MMF_OOM_SKIP		21	/* mm is of no interest for the OOM killer */
> >  #define MMF_UNSTABLE		22	/* mm is unstable for copy_from_user */
> > -#define MMF_HUGE_ZERO_PAGE	23      /* mm has ever used the global huge zero page */
> > -#define MMF_DISABLE_THP		24	/* disable THP for all VMAs */
> > +#define MMF_OOM_VICTIM		23	/* mm is the oom victim */
> > +#define MMF_HUGE_ZERO_PAGE	24      /* mm has ever used the global huge zero page */
> > +#define MMF_DISABLE_THP		25	/* disable THP for all VMAs */
> >  #define MMF_DISABLE_THP_MASK	(1 << MMF_DISABLE_THP)
> >  
> >  #define MMF_INIT_MASK		(MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
> 
> Could we not adjust the bit values, but simply add new one for 
> MMF_OOM_VICTIM?  We have automated tools that look at specific bits in 
> mm->flags and it would be nice to not have them be inconsistent between 
> kernel versions.  Not absolutely required, but nice to avoid.

I just wanted to have those semantically related bits closer
together. But I do not insist on this.
-- 
Michal Hocko
SUSE Labs