All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"markus.t.metzger@gmail.com" <markus.t.metzger@gmail.com>,
	"roland@redhat.com" <roland@redhat.com>,
	"eranian@googlemail.com" <eranian@googlemail.com>,
	"Villacis, Juan" <juan.villacis@intel.com>
Subject: Re: [patch] x86, ptrace: fix double-free on race
Date: Fri, 13 Feb 2009 10:58:47 +0100	[thread overview]
Message-ID: <20090213095847.GA20311@redhat.com> (raw)
In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E4A3D5FC1@irsmsx504.ger.corp.intel.com>

On 02/12, Metzger, Markus T wrote:
>
> >-----Original Message-----
> >From: Oleg Nesterov [mailto:oleg@redhat.com]
> >
> >	static inline void arch_bts_init(struct task_struct *p)
> >	{
> >	#ifdef CONFIG_X86_PTRACE_BTS
> >		if (unlikely(p->bts)) {
> >			p->bts = NULL;
> >			p->bts_buffer = NULL;
> >			p->bts_size = 0;
> >			p->thread.bts_ovfl_signal = 0;
> >		}
> >	#endif /* CONFIG_X86_PTRACE_BTS */
> >	}
>
> It looked cleaner and more consistent to me, that way.
>
> Ptrace passes things down to arch in other cases already,
> e.g. ptrace_detach()->ptrace_disable(), ptrace()->arch_ptrace(),
> ptrace_attach()->arch_ptrace_attach().
>
> I think the function should be in arch/x86/ptrace.c - if we call it from
> ptrace or from arch_dup_task_struct() doesn't really matter.
>
> Do you want me to move the call to arch_dup_task_struct()?

Please do what you like more. We can call this from dup_task_struct()
or even from copy_process(). Actually, the initialization above is not
arch dependent, it only depends on CONFIG_BTS.

> >Btw, just curious, bts_ovfl_signal is not used, except the user can
> >set/get it via PTRACE_BTS_CONFIG/PTRACE_BTS_STATUS ?
>
> It's not really necessary for debugging, but we wanted to get the interface
> general enough to support other use cases.
>
> There's already a PMI interrupt handler in perfmon which handles the PEBS
> buffer overflow. Stephane was planning to extract it so it can be used by
> ds.c. Once that is done, we were planning to move the buffer overflow
> handling for BTS and PEBS into ds.c and enable the feature in ptrace.

OK, thanks. (of course I don't understand this magic, but hopefully
can understand your answer ;)

Oleg.


      reply	other threads:[~2009-02-13 10:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 14:10 [patch] x86, ptrace: fix double-free on race Markus Metzger
2009-02-11 14:45 ` Ingo Molnar
2009-02-11 22:08 ` Oleg Nesterov
2009-02-12  9:15   ` Metzger, Markus T
2009-02-13  9:58     ` Oleg Nesterov [this message]

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=20090213095847.GA20311@redhat.com \
    --to=oleg@redhat.com \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=juan.villacis@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@gmail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    /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.