[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070819085707.GB83@tv-sign.ru>
Date: Sun, 19 Aug 2007 12:57:07 +0400
From: Oleg Nesterov <oleg@...sign.ru>
To: Neil Horman <nhorman@...driver.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: + proc-export-a-processes-resource-limits-via-proc-pid.patch added to -mm tree
On 08/18, Neil Horman wrote:
>
> +static int proc_pid_limits(struct task_struct *task, char *buffer)
> +{
> + unsigned int i;
> + int count = 0;
> + unsigned long flags;
> + char *bufptr = buffer;
> +
> + struct rlimit rlim[RLIM_NLIMITS];
> +
> + rcu_read_lock();
> + lock_task_sighand(task,&flags);
> + if (task->signal == NULL){
> + unlock_task_sighand(task, &flags);
> + rcu_read_unlock();
> + return 0;
> + }
> + memcpy(rlim, task->signal->rlim, sizeof(struct rlimit) * RLIM_NLIMITS);
> + unlock_task_sighand(task, &flags);
> + rcu_read_unlock();
No, no. If lock_task_sighand() fails, ->signal _should be_ == NULL, but the
"if (task->signal == NULL)" check is not reliable, we don't have any barriers
to serialize with __exit_signal().
More importantly, it is very wrong to do unlock_task_sighand() in that case,
this means NULL pointer dereference.
What we need is:
rcu_read_lock();
if (!lock_task_sighand(task, &flags)) {
rcu_read_unlock();
return 0;
}
memcpy(rlim, task->signal->rlim, sizeof(rlim));
unlock_task_sighand(task, &flags);
rcu_read_unlock();
No need to check ->signal != NULL if lock_task_sighand() succeeds.
Oleg.
-
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