All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Michal Hocko <mhocko@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Kyle Walker <kwalker@redhat.com>,
	Christoph Lameter <cl@linux.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stanislav Kozina <skozina@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [patch] mm, oom: remove task_lock protecting comm printing
Date: Wed, 23 Sep 2015 12:30:22 +0300	[thread overview]
Message-ID: <20150923093021.GE12318@esperanza> (raw)
In-Reply-To: <20150923091354.GA640@swordfish>

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'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 tolerate a comm being printed that is in
> > > the middle of an update to avoid taking the lock.
> > > 
> > > Other locations in the kernel have already dropped task_lock() when
> > > printing comm, so this is consistent.
> > 
> > Without the protection, can't reading task->comm race with PR_SET_NAME
> > as described below?
> 
> 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 time window during which tsk->comm
might be not null-terminated, no?

Thanks,
Vladimir

> so it should be
> 
> 	[name\0old_name\0]
> 
> 	-ss
> 
> > 
> > Let T->comm[16] = "name\0rubbish1234"
> > 
> > CPU1                                    CPU2
> > ----                                    ----
> > set_task_comm(T, "longname\0")
> >   T->comm[0] = 'l'
> >   T->comm[1] = 'o'
> >   T->comm[2] = 'n'
> >   T->comm[3] = 'g'
> >   T->comm[4] = 'n'
> >                                         printk("%s\n", T->comm)
> >                                           T->comm = "longnrubbish1234"
> >                                           OOPS: the string is not
> >                                                 nil-terminated!
> >   T->comm[5] = 'a'
> >   T->comm[6] = 'm'
> >   T->comm[7] = 'e'
> >   T->comm[8] = '\0'
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Michal Hocko <mhocko@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Kyle Walker <kwalker@redhat.com>,
	Christoph Lameter <cl@linux.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stanislav Kozina <skozina@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [patch] mm, oom: remove task_lock protecting comm printing
Date: Wed, 23 Sep 2015 12:30:22 +0300	[thread overview]
Message-ID: <20150923093021.GE12318@esperanza> (raw)
In-Reply-To: <20150923091354.GA640@swordfish>

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'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 tolerate a comm being printed that is in
> > > the middle of an update to avoid taking the lock.
> > > 
> > > Other locations in the kernel have already dropped task_lock() when
> > > printing comm, so this is consistent.
> > 
> > Without the protection, can't reading task->comm race with PR_SET_NAME
> > as described below?
> 
> 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 time window during which tsk->comm
might be not null-terminated, no?

Thanks,
Vladimir

> so it should be
> 
> 	[name\0old_name\0]
> 
> 	-ss
> 
> > 
> > Let T->comm[16] = "name\0rubbish1234"
> > 
> > CPU1                                    CPU2
> > ----                                    ----
> > set_task_comm(T, "longname\0")
> >   T->comm[0] = 'l'
> >   T->comm[1] = 'o'
> >   T->comm[2] = 'n'
> >   T->comm[3] = 'g'
> >   T->comm[4] = 'n'
> >                                         printk("%s\n", T->comm)
> >                                           T->comm = "longnrubbish1234"
> >                                           OOPS: the string is not
> >                                                 nil-terminated!
> >   T->comm[5] = 'a'
> >   T->comm[6] = 'm'
> >   T->comm[7] = 'e'
> >   T->comm[8] = '\0'
> 

  reply	other threads:[~2015-09-23  9:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 23:30 [patch] mm, oom: remove task_lock protecting comm printing David Rientjes
2015-09-22 23:30 ` David Rientjes
2015-09-23  7:44 ` Michal Hocko
2015-09-23  7:44   ` Michal Hocko
2015-09-23  8:06 ` Vladimir Davydov
2015-09-23  8:06   ` Vladimir Davydov
2015-09-23  9:13   ` Sergey Senozhatsky
2015-09-23  9:13     ` Sergey Senozhatsky
2015-09-23  9:30     ` Vladimir Davydov [this message]
2015-09-23  9:30       ` Vladimir Davydov
2015-09-23  9:43       ` Michal Hocko
2015-09-23  9:43         ` Michal Hocko
2015-09-23  9:50         ` Sergey Senozhatsky
2015-09-23  9:50           ` Sergey Senozhatsky
2015-09-23  9:57           ` Sergey Senozhatsky
2015-09-23  9:57             ` Sergey Senozhatsky
2015-09-23 10:07           ` Vladimir Davydov
2015-09-23 10:07             ` Vladimir Davydov
2015-09-23 10:41             ` Michal Hocko
2015-09-23 10:41               ` Michal Hocko
2015-09-24 19:45 ` Johannes Weiner
2015-09-24 19:45   ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150923093021.GE12318@esperanza \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=kwalker@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rientjes@google.com \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=skozina@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.