do_wait() changes && 2.6.32 -mm merge plans

[Oleg Nesterov]

On 09/15, Andrew Morton wrote:
>
> ptrace-__ptrace_detach-do-__wake_up_parent-if-we-reap-the-tracee.patch
> do_wait-wakeup-optimization-shift-security_task_wait-from-eligible_child-to-wait_consider_task.patch
> #do_wait-wakeup-optimization-change-__wake_up_parent-to-use-filtered-wakeup.patch: busted (KAMEZAWA)
> do_wait-wakeup-optimization-change-__wake_up_parent-to-use-filtered-wakeup.patch

Hopefully the problem with this one is fixed, thanks again to Kamezawa.

> do_wait-wakeup-optimization-change-__wake_up_parent-to-use-filtered-wakeup-selinux_bprm_committed_creds-use-__wake_up_parent.patch
> do_wait-wakeup-optimization-child_wait_callback-check-__wnothread-case.patch
> do_wait-wakeup-optimization-fix-child_wait_callback-eligible_child-usage.patch
> do_wait-wakeup-optimization-simplify-task_pid_type.patch
> #do_wait-optimization-do-not-place-sub-threads-on-task_struct-children-list.patch: risky?
> do_wait-optimization-do-not-place-sub-threads-on-task_struct-children-list.patch

Yes, risky... God knows who can do list_for_each(->children) and expect to
find the sub-threads. But this is obviously good optimization/simplification.

It is just ugly to place sub-threads on ->children list, this buys nothing
but slown downs do_wait(). (this was needed, afaics, to handle ptraced but
not re-parented threads a long ago).

> wait_consider_task-kill-parent-argument.patch
> do_wait-fix-sys_waitid-specific-behaviour.patch
> wait_noreap_copyout-check-for-wo_info-=-null.patch
>
>   ptrace.  Mostly-merge.

Only the first patch is "ptrace" ;)

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/