Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-24 Thread Johannes Weiner
On Tue, Sep 22, 2015 at 04:30:13PM -0700, David Rientjes wrote: > The oom killer takes task_lock() in a couple of places solely to protect > printing the task's comm. > > A process's comm, including current's comm, may change due to > /proc/pid/comm or PR_SET_NAME. > > The comm will always be NUL

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Michal Hocko
On Wed 23-09-15 13:07:40, Vladimir Davydov wrote: > On Wed, Sep 23, 2015 at 06:50:22PM +0900, Sergey Senozhatsky wrote: > > On (09/23/15 11:43), Michal Hocko wrote: > > [..] > > > > > the previous name was already null terminated, > > > > > > > > Yeah, but if the old name is shorter than the new o

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Vladimir Davydov
On Wed, Sep 23, 2015 at 06:50:22PM +0900, Sergey Senozhatsky wrote: > On (09/23/15 11:43), Michal Hocko wrote: > [..] > > > > the previous name was already null terminated, > > > > > > Yeah, but if the old name is shorter than the new one, set_task_comm() > > > overwrites the terminating null of t

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Sergey Senozhatsky
On (09/23/15 18:50), Sergey Senozhatsky wrote: > On (09/23/15 11:43), Michal Hocko wrote: > [..] > > > > the previous name was already null terminated, > > > > > > Yeah, but if the old name is shorter than the new one, set_task_comm() > > > overwrites the terminating null of the old name before wr

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Sergey Senozhatsky
On (09/23/15 11:43), Michal Hocko wrote: [..] > > > the previous name was already null terminated, > > > > Yeah, but if the old name is shorter than the new one, set_task_comm() > > overwrites the terminating null of the old name before writing the new > > terminating null, so there is a short tim

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Michal Hocko
On Wed 23-09-15 12:30:22, Vladimir Davydov wrote: > On Wed, Sep 23, 2015 at 06:13:54PM +0900, Sergey Senozhatsky wrote: > > On (09/23/15 11:06), Vladimir Davydov wrote: > > > Hi, > > > > > > On Tue, Sep 22, 2015 at 04:30:13PM -0700, David Rientjes wrote: > > > > The oom killer takes task_lock() in

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Vladimir Davydov
On Wed, Sep 23, 2015 at 06:13:54PM +0900, Sergey Senozhatsky wrote: > On (09/23/15 11:06), Vladimir Davydov wrote: > > Hi, > > > > On Tue, Sep 22, 2015 at 04:30:13PM -0700, David Rientjes wrote: > > > The oom killer takes task_lock() in a couple of places solely to protect > > > printing the task'

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Sergey Senozhatsky
On (09/23/15 11:06), Vladimir Davydov wrote: > Hi, > > On Tue, Sep 22, 2015 at 04:30:13PM -0700, David Rientjes wrote: > > The oom killer takes task_lock() in a couple of places solely to protect > > printing the task's comm. > > > > A process's comm, including current's comm, may change due to >

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Vladimir Davydov
Hi, On Tue, Sep 22, 2015 at 04:30:13PM -0700, David Rientjes wrote: > The oom killer takes task_lock() in a couple of places solely to protect > printing the task's comm. > > A process's comm, including current's comm, may change due to > /proc/pid/comm or PR_SET_NAME. > > The comm will always b

Re: [patch] mm, oom: remove task_lock protecting comm printing

2015-09-23 Thread Michal Hocko
On Tue 22-09-15 16:30:13, David Rientjes wrote: > The oom killer takes task_lock() in a couple of places solely to protect > printing the task's comm. > > A process's comm, including current's comm, may change due to > /proc/pid/comm or PR_SET_NAME. > > The comm will always be NULL-terminated, so

[patch] mm, oom: remove task_lock protecting comm printing

2015-09-22 Thread David Rientjes
The oom killer takes task_lock() in a couple of places solely to protect printing the task's comm. A process's comm, including current's comm, may change due to /proc/pid/comm or PR_SET_NAME. The comm will always be NULL-terminated, so the worst race scenario would only be during update. We can