[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DD312B4.7060008@jp.fujitsu.com>
Date: Wed, 18 May 2011 09:28:36 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: john.stultz@...aro.org
CC: linux-kernel@...r.kernel.org, tytso@....edu, rientjes@...gle.com,
dave@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
linux-mm@...ck.org
Subject: Re: [PATCH 1/3] comm: Introduce comm_lock seqlock to protect task->comm
access
(2011/05/17 6:19), 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 spinlock
> 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
> Acked-by: David Rientjes<rientjes@...gle.com>
> Signed-off-by: John Stultz<john.stultz@...aro.org>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.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