[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1105121458130.7530@chino.kir.corp.google.com>
Date: Thu, 12 May 2011 15:00:44 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: John Stultz <john.stultz@...aro.org>
cc: LKML <linux-kernel@...r.kernel.org>, "Ted Ts'o" <tytso@....edu>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org
Subject: Re: [PATCH 1/3] comm: Introduce comm_lock seqlock to protect task->comm
access
On Tue, 10 May 2011, John Stultz wrote:
> The implicit rules for current->comm access being safe without locking
> are no longer true. Accessing current->comm without holding the task
> lock may result in null or incomplete strings (however, access won't
> run off the end of the string).
>
> In order to properly fix this, I've introduced a comm_lock seqlock
> which will protect comm access and modified get_task_comm() and
> set_task_comm() to use it.
>
> Since there are a number of cases where comm access is open-coded
> safely grabbing the task_lock(), we preserve the task locking in
> set_task_comm, so those users are also safe.
>
> With this patch, users that access current->comm without a lock
> are still prone to null/incomplete comm strings, but it should
> be no worse then it is now.
>
> The next step is to go through and convert all comm accesses to
> use get_task_comm(). This is substantial, but can be done bit by
> bit, reducing the race windows with each patch.
>
> CC: Ted Ts'o <tytso@....edu>
> CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> CC: David Rientjes <rientjes@...gle.com>
> CC: Dave Hansen <dave@...ux.vnet.ibm.com>
> CC: Andrew Morton <akpm@...ux-foundation.org>
> CC: linux-mm@...ck.org
> Signed-off-by: John Stultz <john.stultz@...aro.org>
Acked-by: David Rientjes <rientjes@...gle.com>
--
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