Messages in this thread | | | Date | Wed, 20 May 2009 20:21:18 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/5] Split wait_noreap_copyout() |
| |
* Vitaly Mayatskikh <v.mayatskih@gmail.com> wrote:
> At Mon, 11 May 2009 15:25:50 +0200, Vitaly Mayatskikh wrote: > > > > Move getrusage() and put_user() code from wait_noreap_copyout() > > to copy_wait_opts_to_user(). The same code is spreaded across all > > wait_task_*() routines, it's better to reuse one copy. > > > > Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com> > > --- > > kernel/exit.c | 39 +++++++++++++++++++++++---------------- > > 1 files changed, 23 insertions(+), 16 deletions(-) > > > > diff --git a/kernel/exit.c b/kernel/exit.c > > index 25782da..9546362 100644 > > --- a/kernel/exit.c > > +++ b/kernel/exit.c > > @@ -1123,27 +1123,34 @@ static int eligible_child(struct wait_opts *wo, struct task_struct *p) > > return 1; > > } > > > > -static int wait_noreap_copyout(struct wait_opts *wo, struct task_struct *p, > > - pid_t pid, uid_t uid, int why, int status) > > +static int copy_wait_opts_to_user(struct wait_opts *wo, struct task_struct *p, > > + pid_t pid, uid_t uid, int why, int status, int signal) > > { > > - struct siginfo __user *infop; > > + struct siginfo __user *infop = wo->wo_info; > > int retval = wo->wo_rusage > > ? getrusage(p, RUSAGE_BOTH, wo->wo_rusage) : 0; > > > > + if (!retval && infop) { > > + retval = put_user(signal, &infop->si_signo); > ... > > +static int wait_noreap_copyout(struct wait_opts *wo, struct task_struct *p, > > + pid_t pid, uid_t uid, int why, int status) > > +{ > > + int retval = copy_wait_opts_to_user(wo, p, pid, uid, why, status, SIGCHLD); > > put_task_struct(p); > > - infop = wo->wo_info; > > - if (!retval) > > - retval = put_user(SIGCHLD, &infop->si_signo); > ... > > Oleg has pointed me to broken behaviour here. Previously > wait_noreap_copyout was doing unconditional put_user and was returning > EFAULT when infop is NULL. Now it uses copy_wait_opts_to_user, which > checks infop and return NULL in the same case. This change is visible > from userspace in waitid() function. > > There're 2 opportunities how to deal with new behaviour: > > 1. Assume wait_task_zombie had a bug previously, and let this patch go. > 2. Fix copy_wait_opts_to_user to old behaviour by something like: > > if (!retval && (infop || WNOWAIT)) { > > What's your opinion?
I'd suggest a variant of 2: keep this large-ish patch an equivalent transformation - i.e. an impact: cleanup type of change.
Then queue up a patch that removes this quirk. Should this change break any user-space, the quirk can be reinstated promptly, without affecting the cleanups. It will also be a very clear, easy target to bisect to - not obscured by clean-up details.
Does this sound good to you?
Ingo
| |