[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090213095847.GA20311@redhat.com>
Date: Fri, 13 Feb 2009 10:58:47 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: "Metzger, Markus T" <markus.t.metzger@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"hpa@...or.com" <hpa@...or.com>,
"markus.t.metzger@...il.com" <markus.t.metzger@...il.com>,
"roland@...hat.com" <roland@...hat.com>,
"eranian@...glemail.com" <eranian@...glemail.com>,
"Villacis, Juan" <juan.villacis@...el.com>
Subject: Re: [patch] x86, ptrace: fix double-free on race
On 02/12, Metzger, Markus T wrote:
>
> >-----Original Message-----
> >From: Oleg Nesterov [mailto:oleg@...hat.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists