public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ptrace: make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop (v.2)
Date: Tue, 28 Jun 2011 18:35:12 +0200	[thread overview]
Message-ID: <20110628163512.GA11937@redhat.com> (raw)
In-Reply-To: <20110628123823.GD3386@htj.dyndns.org>

On 06/28, Tejun Heo wrote:
>
> Hello,
>
> On Tue, Jun 28, 2011 at 02:30:36PM +0200, Denys Vlasenko wrote:
> > On Tue, Jun 28, 2011 at 10:25 AM, Tejun Heo <tj@kernel.org> wrote:
> > > On Mon, Jun 27, 2011 at 05:18:27PM +0200, Oleg Nesterov wrote:
> > > Yeah, but that's a pretty silly way to do it.  If we make it depend on
> > > PT_SEIZED, we can simply say "if seized, EXEC reports..." but as it
> > > currently stands, it would go like "If the message is non-zero on
> > > EXEC, it indicates...  This behavior is valid since kernel version
> > > x.x.x".
> >
> > This is true for any new addition to API.
> > It starts from some kernel version.
>
> Hmmm... but as I wrote above, we have a choice to make here and the
> two options are clearly different?

I do not really understand your concerns. Yes, yes, yes, if we do not
bind this feauture with PT_SEIZED, then the application has to take
care _if_ it wants to use it without PT_SEIZED. So what? This is the
problem of that application. This change can't break the application
which do not want or do not know about this feature.


And how can we bind it to PT_SEIZED? We can't do something like

	old_pid = 0;
	if (PT_SEIZED) {
		old_pid = task_pid_nr_ns(...);
	}

	...

	ptrace_event(PTRACE_EVENT_EXEC, old_pid);

in search_binary_handler(), this is racy, the tracer can attach in the
window and we want to avoid SIGTRAP.

So, we should pass the valid old_pid to ptrace_event() unconditionally
(btw, Denys, I think we should do this anyway, but perhaps we can do
this later) and then uglify ptrace_event() somehow.

Say,

	static inline void ptrace_event(int event, unsigned long message)
	{
+		if (event == PTRACE_EVENT_EXEC && !PT_SEIZED)
+			message = 0;

		if (unlikely(ptrace_event_enabled(current, event))) {
			current->ptrace_message = message;
			ptrace_notify((event << 8) | SIGTRAP);
		} else if (event == PTRACE_EVENT_EXEC && unlikely(current->ptrace)) {
			/* legacy EXEC report via SIGTRAP */
			send_sig(SIGTRAP, current, 0);
		}
	}

looks a bit ugly. Or, perhaps,

	static inline void ptrace_event(int event, unsigned long message)
	{
		bool enabled = ptrace_event_enabled(current, event);

		if (event == PTRACE_EVENT_EXEC) {
			if (PT_SEIZED) {
				enabled = true;
			} else {
				if (!enabled) {
					send_sig(SIGTRAP, current, 0);
					return;
				}
				message = 0;
			}
		}

		if (enabled) {
			current->ptrace_message = message;
			ptrace_notify((event << 8) | SIGTRAP);
		}
	}

a bit better, bit still not very nice. For what? I tend to agree with
Denys, and I think we should listen to the user-space developer who
actually uses ptrace.


That said, I leave it to you and Denys, personally I am fine either way.

FYI, I need to disappear till Thursday.

Oleg.


  reply	other threads:[~2011-06-28 16:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-26 19:08 [PATCH] ptrace: make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop (v.2) Denys Vlasenko
2011-06-26 20:04 ` Oleg Nesterov
2011-06-27  8:11   ` Tejun Heo
2011-06-27 13:47     ` Oleg Nesterov
2011-06-27 13:52       ` Tejun Heo
2011-06-27 15:18         ` Oleg Nesterov
2011-06-28  8:25           ` Tejun Heo
2011-06-28 12:30             ` Denys Vlasenko
2011-06-28 12:38               ` Tejun Heo
2011-06-28 16:35                 ` Oleg Nesterov [this message]
2011-06-28 16:49                   ` Tejun Heo
2011-06-28  0:31   ` Denys Vlasenko

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=20110628163512.GA11937@redhat.com \
    --to=oleg@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox