[RFC PATCH 0/12 v2] ptrace: introduce task_struct->ptrace_cxt

[RFC PATCH 0/12 v2] ptrace: introduce task_struct->ptrace_cxt

[Oleg Nesterov]

Changes:

	- renames as Ingo suggested

	- use task_lock() instead of cmpxchg() in _alloc()

	- comments update

New patches: move last_siginfo, ptrace_message, ptrace_entry.

Oleg.

Re: [RFC PATCH 0/12 v2] ptrace: introduce task_struct->ptrace_cxt

[Roland McGrath]

5/12 still needs a comment about its assumption that tracehook_init_task()
allocated the struct iff appropriate.  Some log entries (or maybe comments)
I saw said "->pt_*" though that is not the name of the field in the patch.
Other than the task_lock/kfree nit in 4/12 it all looks good to me so far.


Thanks,
Roland

Re: [RFC PATCH 0/12 v2] ptrace: introduce task_struct->ptrace_cxt

[Oleg Nesterov]

On 05/28, Roland McGrath wrote:
>
> 5/12 still needs a comment about its assumption that tracehook_init_task()
> allocated the struct iff appropriate.

Not sure I understand... Where should I put this comment?

> Some log entries (or maybe comments)
> I saw said "->pt_*" though that is not the name of the field in the patch.

Yes, the changelog for 9/12.

> Other than the task_lock/kfree nit in 4/12 it all looks good to me so far.

OK, will redo and resend. Perhaps I should send this series to you
privately? I don't like to flood lkml again, the changes are cosmetic.

Oleg.

Re: [RFC PATCH 0/12 v2] ptrace: introduce task_struct->ptrace_cxt

[Roland McGrath]

> > 5/12 still needs a comment about its assumption that tracehook_init_task()
> > allocated the struct iff appropriate.
> 
> Not sure I understand... Where should I put this comment?

ptrace_init_task, to explain this line:

-	if (unlikely(ptrace)) {
+	if (unlikely(child->ptrace_ctx)) {

> OK, will redo and resend. Perhaps I should send this series to you
> privately? I don't like to flood lkml again, the changes are cosmetic.

:-) Whatever you like.  They will surely be posted at least twice more
before they get merged either way.  The idea that any actual useful patches
might pollute the purity of the lkml stream is amusing.  (Post them twice,
it will nudge up the signal-to-noise ratio. ;-)


Thanks,
Roland