* Oleg Nesterov [2012-10-06 20:53:37]:
> On 10/06, Srikar Dronamraju wrote:
> >
> > >
> > > for the future changes... (say, we can remove bp if consumers do not
> > > want to trace this task). Not sure it makes sense to change it right
> > > now.
> > >
> > > So. Should I leave this patch as is?
* Oleg Nesterov o...@redhat.com [2012-10-06 20:53:37]:
On 10/06, Srikar Dronamraju wrote:
for the future changes... (say, we can remove bp if consumers do not
want to trace this task). Not sure it makes sense to change it right
now.
So. Should I leave this patch as is? Or do
On 10/06, Srikar Dronamraju wrote:
>
> >
> > for the future changes... (say, we can remove bp if consumers do not
> > want to trace this task). Not sure it makes sense to change it right
> > now.
> >
> > So. Should I leave this patch as is? Or do you want me to move this
> > check into
>
> for the future changes... (say, we can remove bp if consumers do not
> want to trace this task). Not sure it makes sense to change it right
> now.
>
> So. Should I leave this patch as is? Or do you want me to move this
> check into handler_chain() and make it return "bool restart"?
Lets
On 10/06, Srikar Dronamraju wrote:
>
> * Oleg Nesterov [2012-09-30 21:42:11]:
>
> > @@ -1391,6 +1392,16 @@ static struct uprobe *find_active_uprobe(unsigned
> > long bp_vaddr, int *is_swbp)
> > if (!uprobe && test_and_clear_bit(MMF_RECALC_UPROBES, >flags))
> >
* Oleg Nesterov [2012-09-30 21:42:11]:
> Strictly speaking this race was added by me in 56bb4cf6. However
> I think that this bug is just another indication that we should
> move copy_insn/uprobe_analyze_insn code from install_breakpoint()
> to uprobe_register(), there are a lot of other reasons
* Oleg Nesterov o...@redhat.com [2012-09-30 21:42:11]:
Strictly speaking this race was added by me in 56bb4cf6. However
I think that this bug is just another indication that we should
move copy_insn/uprobe_analyze_insn code from install_breakpoint()
to uprobe_register(), there are a lot of
On 10/06, Srikar Dronamraju wrote:
* Oleg Nesterov o...@redhat.com [2012-09-30 21:42:11]:
@@ -1391,6 +1392,16 @@ static struct uprobe *find_active_uprobe(unsigned
long bp_vaddr, int *is_swbp)
if (!uprobe test_and_clear_bit(MMF_RECALC_UPROBES, mm-flags))
for the future changes... (say, we can remove bp if consumers do not
want to trace this task). Not sure it makes sense to change it right
now.
So. Should I leave this patch as is? Or do you want me to move this
check into handler_chain() and make it return bool restart?
Lets keep it as
On 10/06, Srikar Dronamraju wrote:
for the future changes... (say, we can remove bp if consumers do not
want to trace this task). Not sure it makes sense to change it right
now.
So. Should I leave this patch as is? Or do you want me to move this
check into handler_chain() and make
On 09/30, Oleg Nesterov wrote:
>
> + if (uprobe && unlikely(!(uprobe->flags & UPROBE_COPY_INSN))) {
> + uprobe = NULL;
> + *is_swbp = 0;
> + }
OOPS. this obvioulsy needs put_uprobe(uprobe). I updated this patch
in my tree.
On 09/30, Oleg Nesterov wrote:
+ if (uprobe unlikely(!(uprobe-flags UPROBE_COPY_INSN))) {
+ uprobe = NULL;
+ *is_swbp = 0;
+ }
OOPS. this obvioulsy needs put_uprobe(uprobe). I updated this patch
in my tree.
12 matches
Mail list logo