On Mon, Aug 13, 2018 at 9:37 PM, Ravi Bangoria
wrote:
> Hi Song,
>
> On 08/13/2018 10:42 PM, Song Liu wrote:
>> On Mon, Aug 13, 2018 at 6:17 AM, Oleg Nesterov wrote:
>>> On 08/13, Ravi Bangoria wrote:
> But damn, process creation (exec) is trivial. We could add a new
> uprobe_exec()
> +static int delayed_uprobe_install(struct vm_area_struct *vma)
> +{
> + struct list_head *pos, *q;
> + struct delayed_uprobe *du;
> + unsigned long vaddr;
> + int ret = 0, err = 0;
> +
> + mutex_lock(&delayed_uprobe_lock);
> + list_for_each_safe(pos, q, &delayed_uprobe_l
Hi Song,
On 08/13/2018 10:42 PM, Song Liu wrote:
> On Mon, Aug 13, 2018 at 6:17 AM, Oleg Nesterov wrote:
>> On 08/13, Ravi Bangoria wrote:
>>>
But damn, process creation (exec) is trivial. We could add a new
uprobe_exec()
hook and avoid delayed_uprobe_install() in uprobe_mmap().
>
On Mon, 13 Aug 2018 20:01:41 -0400
Steven Rostedt wrote:
> On Fri, 10 Aug 2018 23:14:01 -0700
> Song Liu wrote:
>
> > On Fri, Aug 10, 2018 at 12:58 PM, Steven Rostedt
> > wrote:
> > > On Thu, 9 Aug 2018 16:38:28 +0200
> > > Oleg Nesterov wrote:
> > >
> > >> I need to read this (hopeful
On Mon, 13 Aug 2018 13:50:19 +0200
Oleg Nesterov wrote:
> On 08/13, Ravi Bangoria wrote:
> >
> > On 08/11/2018 01:27 PM, Song Liu wrote:
> > >> +
> > >> +static void delayed_uprobe_delete(struct delayed_uprobe *du)
> > >> +{
> > >> + if (!du)
> > >> + return;
> > > Do we r
On Fri, 10 Aug 2018 23:14:01 -0700
Song Liu wrote:
> On Fri, Aug 10, 2018 at 12:58 PM, Steven Rostedt wrote:
> > On Thu, 9 Aug 2018 16:38:28 +0200
> > Oleg Nesterov wrote:
> >
> >> I need to read this (hopefully final) version carefully. I'll try to do
> >> this before next Monday.
> >>
> >
On Mon, Aug 13, 2018 at 6:17 AM, Oleg Nesterov wrote:
> On 08/13, Ravi Bangoria wrote:
>>
>> > But damn, process creation (exec) is trivial. We could add a new
>> > uprobe_exec()
>> > hook and avoid delayed_uprobe_install() in uprobe_mmap().
>>
>> I'm sorry. I didn't get this.
>
> Sorry for confu
On Sun, Aug 12, 2018 at 10:47 PM, Ravi Bangoria
wrote:
> Hi Song,
>
> On 08/11/2018 01:27 PM, Song Liu wrote:
>>> +
>>> +static void delayed_uprobe_delete(struct delayed_uprobe *du)
>>> +{
>>> + if (!du)
>>> + return;
>> Do we really need this check?
>
>
> Not necessary though,
On 08/13, Oleg Nesterov wrote:
>
> On 08/13, Ravi Bangoria wrote:
> >
> > > But damn, process creation (exec) is trivial. We could add a new
> > > uprobe_exec()
> > > hook and avoid delayed_uprobe_install() in uprobe_mmap().
> >
> > I'm sorry. I didn't get this.
>
> Sorry for confusion...
>
> I me
On 08/13/2018 06:47 PM, Oleg Nesterov wrote:
> On 08/13, Ravi Bangoria wrote:
>>
>>> But damn, process creation (exec) is trivial. We could add a new
>>> uprobe_exec()
>>> hook and avoid delayed_uprobe_install() in uprobe_mmap().
>>
>> I'm sorry. I didn't get this.
>
> Sorry for confusion...
>
On 08/13, Ravi Bangoria wrote:
>
> > But damn, process creation (exec) is trivial. We could add a new
> > uprobe_exec()
> > hook and avoid delayed_uprobe_install() in uprobe_mmap().
>
> I'm sorry. I didn't get this.
Sorry for confusion...
I meant, if only exec*( could race with _register(), we c
Hi Oleg,
On 08/13/2018 05:20 PM, Oleg Nesterov wrote:
> On 08/13, Ravi Bangoria wrote:
>>
>> On 08/11/2018 01:27 PM, Song Liu wrote:
+
+static void delayed_uprobe_delete(struct delayed_uprobe *du)
+{
+ if (!du)
+ return;
>>> Do we really need this check
On 08/13, Ravi Bangoria wrote:
>
> On 08/11/2018 01:27 PM, Song Liu wrote:
> >> +
> >> +static void delayed_uprobe_delete(struct delayed_uprobe *du)
> >> +{
> >> + if (!du)
> >> + return;
> > Do we really need this check?
>
> Not necessary though, but I would still like to keep
On 08/13, Srikar Dronamraju wrote:
>
> > +
> > +static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
> > +{
> > + struct delayed_uprobe *du;
> > +
> > + if (delayed_uprobe_check(uprobe, mm))
> > + return 0;
> > +
> > + du = kzalloc(sizeof(*du), GFP_KERNEL);
> >
> +
> +static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
> +{
> + struct delayed_uprobe *du;
> +
> + if (delayed_uprobe_check(uprobe, mm))
> + return 0;
> +
> + du = kzalloc(sizeof(*du), GFP_KERNEL);
> + if (!du)
> + return -ENOMEM;
>
Hi Song,
On 08/13/2018 11:17 AM, Ravi Bangoria wrote:
>>> +
>>> +static void delayed_uprobe_remove(struct uprobe *uprobe, struct mm_struct
>>> *mm)
>>> +{
>>> + struct list_head *pos, *q;
>>> + struct delayed_uprobe *du;
>>> +
>>> + if (!uprobe && !mm)
>>> + return
Hi Song,
On 08/11/2018 01:27 PM, Song Liu wrote:
>> +
>> +static void delayed_uprobe_delete(struct delayed_uprobe *du)
>> +{
>> + if (!du)
>> + return;
> Do we really need this check?
Not necessary though, but I would still like to keep it for a safety.
>
>> + list_d
On Sat, 11 Aug 2018 00:57:12 -0700
Song Liu wrote:
> > +
> > +static void delayed_uprobe_delete(struct delayed_uprobe *du)
> > +{
> > + if (!du)
> > + return;
> Do we really need this check?
I'd suggest we keep it. It's not a fast path, and operations like this
should reall
On Wed, Aug 8, 2018 at 9:18 PM, Ravi Bangoria
wrote:
> Userspace Statically Defined Tracepoints[1] are dtrace style markers
> inside userspace applications. Applications like PostgreSQL, MySQL,
> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
> have these markers embedded in t
On Fri, Aug 10, 2018 at 12:58 PM, Steven Rostedt wrote:
> On Thu, 9 Aug 2018 16:38:28 +0200
> Oleg Nesterov wrote:
>
>> I need to read this (hopefully final) version carefully. I'll try to do
>> this before next Monday.
>>
>
> Monday may be the opening of the merge window (more likely Sunday). Do
On Thu, 9 Aug 2018 16:38:28 +0200
Oleg Nesterov wrote:
> I need to read this (hopefully final) version carefully. I'll try to do
> this before next Monday.
>
Monday may be the opening of the merge window (more likely Sunday). Do
you think this is good enough for pushing it in this late in the g
I need to read this (hopefully final) version carefully. I'll try to do
this before next Monday.
just one note,
On 08/09, Ravi Bangoria wrote:
>
> +static void delayed_uprobe_remove(struct uprobe *uprobe, struct mm_struct
> *mm)
> +{
> + struct list_head *pos, *q;
> + struct delayed_upro
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places
23 matches
Mail list logo
