From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: jan.kratochvil@redhat.com, vda.linux@googlemail.com,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, indan@nul.nu, bdonlan@gmail.com
Subject: Re: [PATCH UPDATED 8/9] ptrace: move JOBCTL_TRAPPING wait to wait(2) and ptrace_check_attach()
Date: Mon, 16 May 2011 14:11:42 +0200 [thread overview]
Message-ID: <20110516121142.GC4898@redhat.com> (raw)
In-Reply-To: <20110514142230.GD23665@htj.dyndns.org>
On 05/14, Tejun Heo wrote:
>
> @@ -1409,15 +1409,29 @@ static int wait_task_stopped(struct wait
> if (!ptrace && !(wo->wo_flags & WUNTRACED))
> return 0;
>
> - if (!task_stopped_code(p, ptrace))
> + /*
> + * For ptrace waits, we can't reliably check whether wait condition
> + * exists without grabbing siglock due to JOBCTL_TRAPPING
> + * transitions. A task might be temporarily in TASK_RUNNING while
> + * trapping which should be transparent to the ptracer.
> + *
> + * Note that we can avoid unconditionally grabbing siglock by
> + * wrapping TRAPPING test with two rmb's; however, let's stick with
> + * simpler implementation for now.
> + */
> + if (!ptrace && !(p->signal->flags & SIGNAL_STOP_STOPPED))
> return 0;
>
> exit_code = 0;
> spin_lock_irq(&p->sighand->siglock);
>
> p_code = task_stopped_code(p, ptrace);
> - if (unlikely(!p_code))
> + if (unlikely(!p_code)) {
> + /* if trapping, wait for it and restart the whole process */
> + if (ptrace && ptrace_wait_trapping(p))
> + return restart_syscall();
Hmm. I didn't even know we have restart_syscall()... It is a bit fragile,
it assumes recalc_sigpending() is not possible during return from syscall.
In particular this means recalc_sigpending() must not be called in irq.
OK, this seems to be true.
Anyway, restart_syscall() is not right for do_wait(), especially with the
next patch. If the caller was woken by the real signal which has a handler,
we should not restart without SA_RESTART.
It is very hard to review this series. Without the further changes, it is
not clear why do we need these preparations. IIUC, ptrace_wait_trapping()
is only needed because we are going to re-trap. Otherwise we could always
wait in ptrace_attach() afaics.
I am still worried we are loosing the tight control over JOBCTL_TRAPPING.
6/9 contributes to this too.
Oleg.
next prev parent reply other threads:[~2011-05-16 12:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 15:46 [PATCHSET ptrace] ptrace: prepare for PTRACE_SEIZE/INTERRUPT Tejun Heo
2011-05-13 15:46 ` [PATCH 1/9] job control: reorganize wait_task_stopped() Tejun Heo
2011-05-16 11:56 ` Oleg Nesterov
2011-05-13 15:46 ` [PATCH 2/9] job control: rename signal->group_stop and flags to jobctl and rearrange flags Tejun Heo
2011-05-13 15:46 ` [PATCH 3/9] ptrace: ptrace_check_attach(): rename @kill to @ignore_state and add comments Tejun Heo
2011-05-13 15:46 ` [PATCH 4/9] ptrace: relocate set_current_state(TASK_TRACED) in ptrace_stop() Tejun Heo
2011-05-16 11:57 ` Oleg Nesterov
2011-05-16 13:16 ` Tejun Heo
2011-05-16 15:51 ` Oleg Nesterov
2011-05-16 15:59 ` Tejun Heo
2011-05-16 16:34 ` Oleg Nesterov
2011-05-13 15:46 ` [PATCH 5/9] job control: introduce JOBCTL_PENDING_MASK and task_clear_jobctl_pending() Tejun Heo
2011-05-13 15:46 ` [PATCH 6/9] job control: make task_clear_jobctl_pending() clear TRAPPING automatically Tejun Heo
2011-05-16 12:25 ` Oleg Nesterov
2011-05-16 13:24 ` Tejun Heo
2011-05-16 16:00 ` Oleg Nesterov
2011-05-16 16:09 ` Tejun Heo
2011-05-13 15:46 ` [PATCH 7/9] ptrace: use bit_waitqueue for TRAPPING instead of wait_chldexit Tejun Heo
2011-05-13 15:46 ` [PATCH 8/9] ptrace: move JOBCTL_TRAPPING wait to wait(2) and ptrace_check_attach() Tejun Heo
2011-05-14 14:22 ` [PATCH UPDATED " Tejun Heo
2011-05-16 12:11 ` Oleg Nesterov [this message]
2011-05-16 13:36 ` Tejun Heo
2011-05-16 16:04 ` Oleg Nesterov
2011-05-13 15:46 ` [PATCH 9/9] ptrace: make TRAPPING wait interruptible Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110516121142.GC4898@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bdonlan@gmail.com \
--cc=indan@nul.nu \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vda.linux@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.