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
>
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
>
> +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(_uprobe_lock);
> + list_for_each_safe(pos, q, _uprobe_list) {
> +
> +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(_uprobe_lock);
> + list_for_each_safe(pos, q, _uprobe_list) {
> +
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().
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
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
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
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
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 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
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
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
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
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
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
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/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
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
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
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
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, 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);
>
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;
> +
> +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)
>>> +
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)
>>> +
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.
>
>> +
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.
>
>> +
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
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
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
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
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).
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).
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
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
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
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
44 matches
Mail list logo
