wait_task_stopped: pass correct exit_code to wait_noreap_copyout
PATCH 1/1 wait_task_stopped: pass correct exit_code to wait_noreap_copyout
In wait_task_stopped() exit_code already contains the right value for the si_status member of siginfo, and this is simply set in the non WNOWAIT case.
Pass it unchanged to wait_noreap_copyout(); we would only need to shift it and add 0x7f if we were returning it in the user status field and that isn't used for any function that permits WNOWAIT.
kernel/exit.c +0 -0
@@ -1389,7 +1389,7 @@ static int wait_task_stopped(struct task_struct
*p, int delayed_group_leader,
if (unlikely(!exit_code) || unlikely(p->exit_state))
goto bail_ref;
return wait_noreap_copyout(p, pid, uid,
- why, (exit_code << 8) | 0x7f,
+ why, exit_code,
infop, ru);
}
Quoted 15 lines · On Sun, 18 Nov 2007 09:13:24 +0000 Scott James Remnant <[email protected]> wrote:
In
wait_task_stopped()exit_codealready contains the right value for thesi_statusmember of siginfo, and this is simply set in the non WNOWAIT case.Pass it unchanged to
wait_noreap_copyout(); we would only need to shift it and add0x7fif we were returning it in the user status field and that isn't used for any function that permits WNOWAIT.Signed-off-by Scott James Remnant <[email protected]>Signed-off-by Oleg Nesterov <[email protected]>Signed-off-by Roland McGrath <[email protected]>
kernel/exit.c static int wait_task_stopped(struct task_struct · line 1395
Quoted 8 lines
kernel/exit.c +1
-1@@ -1389,7 +1389,7 @@ static int wait_task_stopped(struct task_struct *p, int delayed_group_leader, if (unlikely(!exit_code) || unlikely(p->exit_state)) goto bail_ref;return wait_noreap_copyout (p, pid, uid, - why, (exit_code <<8 ) |0x7f , + why, exit_code, infop, ru); }
Is this bug visible to userspace? If so, I'm surprised that none of the various testsuites (which like to exercise this sort of interface) has detected it.
Quoted 6 lines · Andrew Morton
Quoted 4 lines · On Sun, 18 Nov 2007 09:13:24 +0000 Scott James Remnant <[email protected]> wrote:
In
wait_task_stopped()exit_codealready contains the right value for thesi_statusmember of siginfo, and this is simply set in the non WNOWAIT case.
Quoted 8 lines
Quoted 4 lines
Pass it unchanged to
wait_noreap_copyout(); we would only need to shift it and add0x7fif we were returning it in the user status field and that isn't used for any function that permits WNOWAIT.Is this bug visible to userspace? If so, I'm surprised that none of the various testsuites (which like to exercise this sort of interface) has detected it.
Absolutely; if you call waitid() with a stopped or traced process, you'll get the signal in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the same time, you'll get the signal << 8 | 0x7f
Scott
Signature · 2 lines
Scott James Remnant [email protected]
Quoted 11 lines · On Tue, 20 Nov 2007 07:55:22 +0000 Scott James Remnant <[email protected]> wrote:
Quoted 10 lines · Andrew Morton
Quoted 8 lines · On Sun, 18 Nov 2007 09:13:24 +0000 Scott James Remnant <[email protected]> wrote:
In
wait_task_stopped()exit_codealready contains the right value for thesi_statusmember of siginfo, and this is simply set in the non WNOWAIT case.Pass it unchanged to
wait_noreap_copyout(); we would only need to shift it and add0x7fif we were returning it in the user status field and that isn't used for any function that permits WNOWAIT.
Quoted 8 lines
Quoted 4 lines
Is this bug visible to userspace? If so, I'm surprised that none of the various testsuites (which like to exercise this sort of interface) has detected it.
Absolutely; if you call
waitid()with a stopped or traced process, you'll get the signal in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the same time, you'll get the signal << 8 |0x7f
hm, OK. Well I guess I'll stick a for-2.6.23 tag on this as well as queueing it for 2.6.24.