lkml.org 
[lkml]   [2010]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] CRED: Fix __task_cred()'s lockdep check and banner comment
On Thu, Jul 29, 2010 at 12:45:55PM +0100, David Howells wrote:
> Fix __task_cred()'s lockdep check by removing the following validation
> condition:
>
> lockdep_tasklist_lock_is_held()
>
> as commit_creds() does not take the tasklist_lock, and nor do most of the
> functions that call it, so this check is pointless and it can prevent
> detection of the RCU lock not being held if the tasklist_lock is held.
>
> Instead, add the following validation condition:
>
> task->exit_state >= 0
>
> to permit the access if the target task is dead and therefore unable to change
> its own credentials.
>
>
> Fix __task_cred()'s comment to:
>
> (1) discard the bit that says that the caller must prevent the target task
> from being deleted. That shouldn't need saying.
>
> (2) Add a comment indicating the result of __task_cred() should not be passed
> directly to get_cred(), but rather than get_task_cred() should be used
> instead.
>
> Also put a note into the documentation to enforce this point there too.

Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

> Signed-off-by: David Howells <dhowells@redhat.com>
> Acked-by: Jiri Olsa <jolsa@redhat.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> Documentation/credentials.txt | 3 +++
> include/linux/cred.h | 15 ++++++++++-----
> include/linux/sched.h | 1 +
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/credentials.txt b/Documentation/credentials.txt
> index a2db352..995baf3 100644
> --- a/Documentation/credentials.txt
> +++ b/Documentation/credentials.txt
> @@ -417,6 +417,9 @@ reference on them using:
> This does all the RCU magic inside of it. The caller must call put_cred() on
> the credentials so obtained when they're finished with.
>
> + [*] Note: The result of __task_cred() should not be passed directly to
> + get_cred() as this may race with commit_cred().
> +
> There are a couple of convenience functions to access bits of another task's
> credentials, hiding the RCU magic from the caller:
>
> diff --git a/include/linux/cred.h b/include/linux/cred.h
> index ce40cbc..4d2c395 100644
> --- a/include/linux/cred.h
> +++ b/include/linux/cred.h
> @@ -274,13 +274,18 @@ static inline void put_cred(const struct cred *_cred)
> * @task: The task to query
> *
> * Access the objective credentials of a task. The caller must hold the RCU
> - * readlock.
> + * readlock or the task must be dead and unable to change its own credentials.
> *
> - * The caller must make sure task doesn't go away, either by holding a ref on
> - * task or by holding tasklist_lock to prevent it from being unlinked.
> + * The result of this function should not be passed directly to get_cred();
> + * rather get_task_cred() should be used instead.
> */
> -#define __task_cred(task) \
> - ((const struct cred *)(rcu_dereference_check((task)->real_cred, rcu_read_lock_held() || lockdep_tasklist_lock_is_held())))
> +#define __task_cred(task) \
> + ({ \
> + const struct task_struct *__t = (task); \
> + rcu_dereference_check(__t->real_cred, \
> + rcu_read_lock_held() || \
> + task_is_dead(__t)); \
> + })
>
> /**
> * get_current_cred - Get the current task's subjective credentials
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 747fcae..0478888 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -214,6 +214,7 @@ extern char ___assert_task_state[1 - 2*!!(
>
> #define task_is_traced(task) ((task->state & __TASK_TRACED) != 0)
> #define task_is_stopped(task) ((task->state & __TASK_STOPPED) != 0)
> +#define task_is_dead(task) ((task)->exit_state != 0)
> #define task_is_stopped_or_traced(task) \
> ((task->state & (__TASK_STOPPED | __TASK_TRACED)) != 0)
> #define task_contributes_to_load(task) \
>


\
 
 \ /
  Last update: 2010-08-02 22:43    [W:1.838 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site