[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150923095022.GB640@swordfish>
Date: Wed, 23 Sep 2015 18:50:22 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Vladimir Davydov <vdavydov@...allels.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Kyle Walker <kwalker@...hat.com>,
Christoph Lameter <cl@...ux.com>,
Johannes Weiner <hannes@...xchg.org>,
linux-mm <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stanislav Kozina <skozina@...hat.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [patch] mm, oom: remove task_lock protecting comm printing
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 time window during which tsk->comm
> > might be not null-terminated, no?
>
> Not really:
> case PR_SET_NAME:
> comm[sizeof(me->comm) - 1] = 0;
> if (strncpy_from_user(comm, (char __user *)arg2,
> sizeof(me->comm) - 1) < 0)
> return -EFAULT;
>
> So it first writes the terminating 0 and only then starts copying.
right.
hm, shouldn't set_task_comm()->__set_task_comm() do the same?
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists