All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] syscalls/ptrace11: Add test for tracing init process
Date: Mon, 16 Nov 2020 18:51:30 +0800	[thread overview]
Message-ID: <5FB259B2.4040106@cn.fujitsu.com> (raw)
In-Reply-To: <20201113151239.GB16315@yuki.lan>

Hi Cyril
> Hi!
>> +	/*
>> +	 * Running attach/detach more times will trigger a ESRCH error because
>> +	 * ptrace_check_attach function in kernel will report it if its process
>> +	 * stats is not __TASK_TRACED.
>> +	 */
>> +	TST_RETRY_FUNC(ptrace(PTRACE_DETACH, 1, NULL, NULL), TST_RETVAL_EQ0);
>
> Why do we have to retry the detach here?

I add a retry here because running attach/detach serval times may make 
init process isn't traced status . Even we have do attach action, detach 
will get ESRCH error .

In kernel/ptrace.c code, it has the following calltrace
SYSCALL_DEFINE4(ptrace...
    =>ptrace_check_attach   //if we don't use PTRACE_ATTACH/PTRACE_SEIZE
      =>ptrace_freeze_traced

/* Ensure that nothing can wake it up, even SIGKILL */
static bool ptrace_freeze_traced(struct task_struct *task)
{
         bool ret = false;

         /* Lockless, nobody but us can set this flag */
         if (task->jobctl & JOBCTL_LISTENING)
                 return ret;
         spin_lock_irq(&task->sighand->siglock);
         if (task_is_traced(task) && !__fatal_signal_pending(task)) {
                 task->state = __TASK_TRACED;
                 ret = true;
         }
         spin_unlock_irq(&task->sighand->siglock);

         return ret;
}

ptrace_freeze_traced() may returns false when we run attach/detach 
serval times, so ptrace_check_attach returns ESRCH error .

To be honset, I don't figure out why task->stat is not task_traced 
status after attaching. I am looking into this.

Best Regards
Yang Xu
>
> Other than that the rest looks fine now.
>




  reply	other threads:[~2020-11-16 10:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 11:43 [LTP] [PATCH 2/2] syscalls/ptrace02: Add another EPERM error test Yang Xu
2020-11-11 15:09 ` Cyril Hrubis
2020-11-12  6:31   ` Yang Xu
2020-11-12  6:48   ` [LTP] [PATCH v2 1/2] " Yang Xu
2020-11-12  6:48     ` [LTP] [PATCH v2 2/2] syscalls/ptrace11: Add test for tracing init process Yang Xu
2020-11-12 10:32       ` Cyril Hrubis
2020-11-12 12:05         ` Cyril Hrubis
2020-11-13  1:33           ` Yang Xu
2020-11-13  2:07           ` [LTP] [PATCH v3] " Yang Xu
2020-11-13 15:12             ` Cyril Hrubis
2020-11-16 10:51               ` Yang Xu [this message]
2020-11-19 15:31                 ` Cyril Hrubis
2020-11-20  2:30                   ` Yang Xu
2020-11-20  3:16                   ` [LTP] [PATCH v4] " Yang Xu
2020-11-20 10:16                     ` Cyril Hrubis
2020-11-12 10:27     ` [LTP] [PATCH v2 1/2] syscalls/ptrace02: Add another EPERM error test Cyril Hrubis
2020-11-12 10:31       ` Cyril Hrubis
2020-11-13  1:29         ` Yang Xu

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=5FB259B2.4040106@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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.