[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20090526204846.898CCFC2BD@magilla.sf.frob.com>
Date: Tue, 26 May 2009 13:48:46 -0700 (PDT)
From: Roland McGrath <roland@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/X] ptrace: introduce the empty "struct ptrace_task"
> /**
> + * tracehook_init_task - initialize the new child
> + * @child: new child task
s/child/task/
> + * @clone_flags: %CLONE_* flags from clone/fork/vfork system call
> + * @trace: return value from tracehook_prepare_clone()
> + *
> + * This is called immediately after dup_task_struct().
* It must clear/reset any tracing state so that tracehook_free_task()
* will work safely if the task creation fails. If the task creation
* succeeds, a tracehook_finish_clone() call will follow with locks
* held, before @task starts or is accessible to anyone else.
> +int alloc_ptrace_task(struct task_struct *tsk)
This deserves a short comment about the context it's called from,
and when it is or isn't called at all.
> + if (cmpxchg(&tsk->ptrace_task, NULL, ptrace_task) != NULL)
> + kfree(ptrace_task);
I don't see cmpxchg() used very often at all in generic kernel code. I
wonder how good a choice it is across every arch. Is there a reason not to
use e.g. task_lock() to mediate installing a new ->ptrace_task pointer?
That seems like a more conservative route.
Thanks,
Roland
--
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