2002-09-01 17:33:46

by OGAWA Hirofumi

Subject: [PATCH] remove BUG_ON(p->ptrace) in release_task()

Hi,

I think, BUG_ON(p->ptrace) will be called if the CLONE_DETACH process
is traced. This patch removes BUG_ON(p->ptrace), and also removes
BUG_ON(p->ptrace) workaround in sys_wait4().

Please apply.
--
OGAWA Hirofumi <[email protected]>

--- linux-2.5.33/kernel/exit.c~ 2002-09-02 01:02:07.000000000 +0900
+++ linux-2.5.33/kernel/exit.c 2002-09-02 00:54:47.000000000 +0900
@@ -66,8 +66,7 @@
atomic_dec(&p->user->processes);
security_ops->task_free_security(p);
free_uid(p->user);
- BUG_ON(p->ptrace || !list_empty(&p->ptrace_list) ||
- !list_empty(&p->ptrace_children));
+ BUG_ON(!list_empty(&p->ptrace_list)||!list_empty(&p->ptrace_children));
unhash_process(p);

release_thread(p);
@@ -717,14 +716,8 @@
ptrace_unlink(p);
do_notify_parent(p, SIGCHLD);
write_unlock_irq(&tasklist_lock);
- } else {
- if (p->ptrace) {
- write_lock_irq(&tasklist_lock);
- ptrace_unlink(p);
- write_unlock_irq(&tasklist_lock);
- }
+ } else
release_task(p);
- }
goto end_wait4;
default:
continue;

2002-09-01 19:27:35

by Daniel Jacobowitz

Subject: Re: [PATCH] remove BUG_ON(p->ptrace) in release_task()

On Mon, Sep 02, 2002 at 02:38:03AM +0900, OGAWA Hirofumi wrote:
> Hi,
>
> I think, BUG_ON(p->ptrace) will be called if the CLONE_DETACH process
> is traced. This patch removes BUG_ON(p->ptrace), and also removes
> BUG_ON(p->ptrace) workaround in sys_wait4().

The BUG_ON is correct, and that isn't a workaround - if the list is not
empty, then it will be garbage after the task struct is freed. Your
patch breaks tracing of normal processes again, because the ptrace_list
will not be empty.

It may be that the BUG_ON can be triggered for detached processes. In
that case a ptrace_unlink is necessary somewhere else.

>
> Please apply.
> --
> OGAWA Hirofumi <[email protected]>
>
> --- linux-2.5.33/kernel/exit.c~ 2002-09-02 01:02:07.000000000 +0900
> +++ linux-2.5.33/kernel/exit.c 2002-09-02 00:54:47.000000000 +0900
> @@ -66,8 +66,7 @@
> atomic_dec(&p->user->processes);
> security_ops->task_free_security(p);
> free_uid(p->user);
> - BUG_ON(p->ptrace || !list_empty(&p->ptrace_list) ||
> - !list_empty(&p->ptrace_children));
> + BUG_ON(!list_empty(&p->ptrace_list)||!list_empty(&p->ptrace_children));
> unhash_process(p);
>
> release_thread(p);
> @@ -717,14 +716,8 @@
> ptrace_unlink(p);
> do_notify_parent(p, SIGCHLD);
> write_unlock_irq(&tasklist_lock);
> - } else {
> - if (p->ptrace) {
> - write_lock_irq(&tasklist_lock);
> - ptrace_unlink(p);
> - write_unlock_irq(&tasklist_lock);
> - }
> + } else
> release_task(p);
> - }
> goto end_wait4;
> default:
> continue;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

2002-09-02 13:29:09

by OGAWA Hirofumi

Subject: Re: [PATCH] remove BUG_ON(p->ptrace) in release_task()

Daniel Jacobowitz <[email protected]> writes:

> On Mon, Sep 02, 2002 at 02:38:03AM +0900, OGAWA Hirofumi wrote:
> > Hi,
> >
> > I think, BUG_ON(p->ptrace) will be called if the CLONE_DETACH process
> > is traced. This patch removes BUG_ON(p->ptrace), and also removes
> > BUG_ON(p->ptrace) workaround in sys_wait4().
>
> The BUG_ON is correct, and that isn't a workaround - if the list is not
> empty, then it will be garbage after the task struct is freed. Your
> patch breaks tracing of normal processes again, because the ptrace_list
> will not be empty.

Whoops, yes, I'm wrong. Sorry. My fixes wasn't enough. However, looks
like your case called the following BUG().

sys_ptrace()
-> ptrace_attach()
-> __ptrace_link()

void __ptrace_link(task_t *child, task_t *new_parent)
{
if (!list_empty(&child->ptrace_list))
BUG();
if (child->parent == new_parent)
BUG(); <--- this
list_add(&child->ptrace_list, &child->parent->ptrace_children);
REMOVE_LINKS(child);

So, I need to look source more. Thanks.
--
OGAWA Hirofumi <[email protected]>