All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>,
	Heiko Carstens <heicars2@linux.vnet.ibm.com>,
	sameske@linux.vnet.ibm.com,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [RFC] [Patch 1/1] [Self Ptrace] System call notification with self_ptrace
Date: Tue, 26 Aug 2008 16:04:15 +0200	[thread overview]
Message-ID: <48B40D5F.3020705@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080825165403.GA604@tv-sign.ru>

Hello Oleg,

Oleg Nesterov wrote:
> On 08/25, Pierre Morel wrote:
>   
>> @@ -550,6 +550,23 @@ asmlinkage long sys_ptrace(long request,
>>  		goto out;
>>  	}
>>
>> +	if (request == PTRACE_SELF_ON) {
>> +		task_lock(current);
>> +		set_thread_flag(TIF_SYSCALL_TRACE);
>> +		current->ptrace |= PT_SELF;
>>     
>
> I didn't read the whole patch, but this sets PT_SELF without PT_PTRACED
> (and without ptrace_attach).
>   
Yes it is the way it is intended to work.
PT_SELF and other ptrace requests are not correlated,
I use the ptrace infrastructure to take advantage
of the existing system call interception framework.
> We have some "->ptrace != 0" checks which can misunderstand this. Just
> for example, suppose that the task does sys_ptrace(PTRACE_SELF_ON) and
> then its parent dies. I guess in that case forget_original_parent()
> will hit BUG_ON(p->ptrace), no?
>
>   
Yes you are right, I will take care of those cases.
I have the choice between:

- tracking all references to the ptrace flags and add a test for PT_SELF
or a mask.

- add a dedicated task_struct entry to hold the PT_SELF flag

The second solution seems easier, simpler and more
readable but extends the task struct.

What do you think is the best way to do it?

> Oleg.
>
>   
Thanks,

Pierre




-- 
=============
Pierre Morel
RTOS and Embedded Linux


  reply	other threads:[~2008-08-26 14:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-25  7:34 [RFC] [Patch 1/1] [Self Ptrace] System call notification with self_ptrace Pierre Morel
2008-08-25 16:33 ` Dave Hansen
2008-08-26 12:33   ` Pierre Morel
2008-08-25 16:54 ` Oleg Nesterov
2008-08-26 14:04   ` Pierre Morel [this message]
2008-08-26 16:27     ` Oleg Nesterov
2008-08-27 14:32       ` Pierre Morel
2008-08-27 16:24         ` Oleg Nesterov
2008-08-28 12:03           ` Pierre Morel
2008-08-28 12:32             ` Oleg Nesterov
2008-08-28 13:24               ` Pierre Morel

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=48B40D5F.3020705@linux.vnet.ibm.com \
    --to=pmorel@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=heicars2@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    --cc=sameske@linux.vnet.ibm.com \
    --cc=schwidefsky@de.ibm.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.