All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Cc: srikar@linux.vnet.ibm.com, rostedt@goodmis.org,
	mhiramat@kernel.org, liu.song.a23@gmail.com,
	peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	alexander.shishkin@linux.intel.com, jolsa@redhat.com,
	namhyung@kernel.org, linux-kernel@vger.kernel.org,
	ananth@linux.vnet.ibm.com, alexis.berlemont@gmail.com,
	naveen.n.rao@linux.vnet.ibm.com,
	linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org,
	linux@armlinux.org.uk, ralf@linux-mips.org, paul.burton@mips.com
Subject: Re: [PATCH v7 3/6] Uprobes: Support SDT markers having reference count (semaphore)
Date: Tue, 7 Aug 2018 13:36:23 +0200	[thread overview]
Message-ID: <20180807113622.GC19831@redhat.com> (raw)
In-Reply-To: <bfb47985-8f58-e5e4-f8b4-695dfea7937f@linux.ibm.com>

Hi Ravi,

On 08/06, Ravi Bangoria 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);
> >> +	if (!du)
> >> +		return -ENOMEM;
> >> +
> >> +	du->uprobe = uprobe;
> >> +	du->mm = mm;
> >
> > I am surprised I didn't notice this before...
> >
> > So
> > 	du->mm = mm;
> >
> > is fine, mm can't go away, uprobe_clear_state() does delayed_uprobe_remove(NULL,mm).
> >
> > But
> > 	du->uprobe = uprobe;
> >
> > doesn't look right, uprobe can go away and it can be freed, its memory can be reused.
> > We can't rely on remove_breakpoint(),
>
>
> I'm sorry. I didn't get this. How can uprobe go away without calling
>     uprobe_unregister()
>     -> rergister_for_each_vma()
>        -> remove_breakpoint()
> And remove_breakpoint() will get called

assuming that _unregister() will find the same vma with the probed insn. But
as I said, the application can munmap the probed page/vma.

No?

> > Also. delayed_uprobe_add() should check the list and avoid duplicates. Otherwise the
> > trivial
> >
> > 	for (;;)
> > 		munmap(mmap(uprobed_file));
> >
> > will eat the memory until uprobe is unregistered.
>
>
> I'm already calling delayed_uprobe_check(uprobe, mm) from delayed_uprobe_add().

Oops ;)

Oleg.

WARNING: multiple messages have this Message-ID (diff)
From: oleg@redhat.com (Oleg Nesterov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 3/6] Uprobes: Support SDT markers having reference count (semaphore)
Date: Tue, 7 Aug 2018 13:36:23 +0200	[thread overview]
Message-ID: <20180807113622.GC19831@redhat.com> (raw)
In-Reply-To: <bfb47985-8f58-e5e4-f8b4-695dfea7937f@linux.ibm.com>

Hi Ravi,

On 08/06, Ravi Bangoria 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);
> >> +	if (!du)
> >> +		return -ENOMEM;
> >> +
> >> +	du->uprobe = uprobe;
> >> +	du->mm = mm;
> >
> > I am surprised I didn't notice this before...
> >
> > So
> > 	du->mm = mm;
> >
> > is fine, mm can't go away, uprobe_clear_state() does delayed_uprobe_remove(NULL,mm).
> >
> > But
> > 	du->uprobe = uprobe;
> >
> > doesn't look right, uprobe can go away and it can be freed, its memory can be reused.
> > We can't rely on remove_breakpoint(),
>
>
> I'm sorry. I didn't get this. How can uprobe go away without calling
>     uprobe_unregister()
>     -> rergister_for_each_vma()
>        -> remove_breakpoint()
> And remove_breakpoint() will get called

assuming that _unregister() will find the same vma with the probed insn. But
as I said, the application can munmap the probed page/vma.

No?

> > Also. delayed_uprobe_add() should check the list and avoid duplicates. Otherwise the
> > trivial
> >
> > 	for (;;)
> > 		munmap(mmap(uprobed_file));
> >
> > will eat the memory until uprobe is unregistered.
>
>
> I'm already calling delayed_uprobe_check(uprobe, mm) from delayed_uprobe_add().

Oops ;)

Oleg.

  reply	other threads:[~2018-08-07 11:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31  3:51 [PATCH v7 0/6] Uprobes: Support SDT markers having reference count (semaphore) Ravi Bangoria
2018-07-31  3:51 ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 1/6] Uprobes: Simplify uprobe_register() body Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 2/6] Uprobe: Additional argument arch_uprobe to uprobe_write_opcode() Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 3/6] Uprobes: Support SDT markers having reference count (semaphore) Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria
2018-08-03 11:24   ` Oleg Nesterov
2018-08-03 11:24     ` Oleg Nesterov
2018-08-06  9:52     ` Ravi Bangoria
2018-08-06  9:52       ` Ravi Bangoria
2018-08-07 11:36       ` Oleg Nesterov [this message]
2018-08-07 11:36         ` Oleg Nesterov
2018-08-07 12:33         ` Ravi Bangoria
2018-08-07 12:33           ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 4/6] Uprobes/sdt: Prevent multiple reference counter for same uprobe Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 5/6] trace_uprobe/sdt: " Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria
2018-07-31  3:51 ` [PATCH v7 6/6] perf probe: Support SDT markers having reference counter (semaphore) Ravi Bangoria
2018-07-31  3:51   ` Ravi Bangoria

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=20180807113622.GC19831@redhat.com \
    --to=oleg@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexis.berlemont@gmail.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux@armlinux.org.uk \
    --cc=liu.song.a23@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=paul.burton@mips.com \
    --cc=peterz@infradead.org \
    --cc=ralf@linux-mips.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    /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.