Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-06-01 Thread Michal Hocko
On Wed 01-06-16 00:29:33, Oleg Nesterov wrote: > On 05/31, Michal Hocko wrote: > > > > On Mon 30-05-16 19:35:05, Oleg Nesterov wrote: > > > > > > Well, let me suggest this again. I think it should do > > > > > > > > > if (SIGNAL_GROUP_COREDUMP) > > > return false; > > > > > > if (SIGN

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-31 Thread Oleg Nesterov
On 05/31, Michal Hocko wrote: > > On Mon 30-05-16 19:35:05, Oleg Nesterov wrote: > > > > Well, let me suggest this again. I think it should do > > > > > > if (SIGNAL_GROUP_COREDUMP) > > return false; > > > > if (SIGNAL_GROUP_EXIT) > > return true; > > > > if (thr

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-31 Thread Michal Hocko
On Mon 30-05-16 19:35:05, Oleg Nesterov wrote: > On 05/30, Michal Hocko wrote: > > > > task_will_free_mem is rather weak. > > I was thinking about the similar change because I noticed that > try_oom_reaper() > is very, very wrong. > > To the point I think that we need another change for stable w

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-30 Thread Oleg Nesterov
On 05/30, Michal Hocko wrote: > > task_will_free_mem is rather weak. I was thinking about the similar change because I noticed that try_oom_reaper() is very, very wrong. To the point I think that we need another change for stable which simply removes spin_lock_irq(sighand->siglock) from try_oom_r

[PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-30 Thread Michal Hocko
From: Michal Hocko task_will_free_mem is rather weak. It doesn't really tell whether the task has chance to drop its mm. 98748bd72200 ("oom: consider multi-threaded tasks in task_will_free_mem") made a first step into making it more robust for multi-threaded applications so now we know that the w

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-27 Thread Michal Hocko
I have updated the patch to not rely on the mm_users check because it is not reliable as pointed by Tetsuo and we really want this function to be reliable. I do not have a good and reliable way to check for existence of external users sharing the mm so we are checking the whole list unconditionally

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-26 Thread Michal Hocko
On Thu 26-05-16 23:41:54, Tetsuo Handa wrote: > Michal Hocko wrote: > > +/* > > + * Checks whether the given task is dying or exiting and likely to > > + * release its address space. This means that all threads and processes > > + * sharing the same mm have to be killed or exiting. > > + */ > > +st

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-26 Thread Tetsuo Handa
Michal Hocko wrote: > +/* > + * Checks whether the given task is dying or exiting and likely to > + * release its address space. This means that all threads and processes > + * sharing the same mm have to be killed or exiting. > + */ > +static inline bool task_will_free_mem(struct task_struct *task

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-26 Thread Michal Hocko
On Thu 26-05-16 23:11:47, Tetsuo Handa wrote: [...] > > + if (mm) { > > + rcu_read_lock(); > > + for_each_process(p) { > > + bool vfork; > > + > > + /* > > +* skip over vforked tasks because they are mostly > > +

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-26 Thread Tetsuo Handa
Michal Hocko wrote: > +/* > + * Checks whether the given task is dying or exiting and likely to > + * release its address space. This means that all threads and processes > + * sharing the same mm have to be killed or exiting. > + */ > +static inline bool task_will_free_mem(struct task_struct *task

[PATCH 6/6] mm, oom: fortify task_will_free_mem

2016-05-26 Thread Michal Hocko
From: Michal Hocko task_will_free_mem is rather weak. It doesn't really tell whether the task has chance to drop its mm. 98748bd72200 ("oom: consider multi-threaded tasks in task_will_free_mem") made a first step into making it more robust for multi-threaded applications so now we know that the w