From: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
rostedt@goodmis.org, mhiramat@kernel.org, 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,
corbet@lwn.net, linux-doc@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,
Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Subject: Re: [PATCH v5 06/10] Uprobes: Support SDT markers having reference count (semaphore)
Date: Tue, 3 Jul 2018 13:13:58 +0530 [thread overview]
Message-ID: <c21db380-7dc0-2165-8616-8dcb519aa787@linux.ibm.com> (raw)
In-Reply-To: <20180703061612.GG65296@linux.vnet.ibm.com>
Hi Srikar,
On 07/03/2018 11:46 AM, Srikar Dronamraju wrote:
>> Current approach:
>>
>> ------------
>> register_for_each_vma() / uprobe_mmap()
>> install_breakpoint()
>> uprobe_write_opcode() {
>> if (instruction is not already patched) {
>> /* Gets called only _once_. */
>> increment the reference counter;
>> patch the instruction;
>> }
>> }
>> ------------
>>
>
> Lets say a user just installs a breakpoint which is part of USDT (using
> either a trace or perf (or some other utility)
> Since the semaphore is not updated, it never hits the probe.
> This is correct.
>
> Now he toggles the semaphore and places a probe at the same spot using
> systemtap or bcc.
> The probes will now be active and we see hits.
> This is also correct.
>
> If the user toggles the semaphore or deletes the probe using
> systemtap/bcc. The probes will still be active.
> Since the reference count is removed on the last consumer deletion. No?
> This may be wrong because, we may be unnecessarily hitting the probes.
I'm not sure if I get your concerns but let me try to explain what happens
in such cases. please let me know if I misunderstood your point.
1. Install a probe using perf.
# ./perf probe sdt_tick:loop2
This does not do anything. Just creates an entry in trace_uprobe.
2. Start record using perf:
# ./perf record -a -e sdt_tick:loop2
This will call uprobe_register_refctr(inode, offfset, ref_ctr_offset)
and will create an object of struct uprobe.
3. Start target process
# ./tick
When we start 'tick', kernel will load the binary and start creating
vmas, which will basically call uprobe_mmap(). First vma will be of
text section and thus instruction will be patched. But vma holding
reference counter is not present yet and thus the uprobe will be
added to delayed_uprobe_list. Now kernel will map the data section
holding reference counter and uprobe_mmap() will check for any
delayed_uprobe. It will find the uprobe and thus it will increment
the reference counter.
So, Reference counter = 1, instruction is patched with trap.
4. For simplicity, I'm using kernel module instead of systemtap / bcc.
User loads a kernel module that registers a probe on the same uprobe
by calling uprobe_register_refctr(inode, offset, ref_ctr_offset).
# insmod test-sdt.ko
The sequence of function call here will be:
uprobe_register_refctr()
register_for_each_vma()
install_breakpoint()
set_swbp()
uprobe_write_opcode()
But uprobe_write_opcode will find instruction is already patched and
thus return without doing anything.
So, Reference counter = 1, instruction is patched.
5. Let's say user kills perf record started in step 2. Function call
sequence here will be:
uprobe_unregister()
register_for_each_vma() {
if (!filter_chain())
remove_breakpoint();
}
Here filter_chain return true because other consumer is active on the
same uprobe. so uprobe_unregister() will return without doing anything.
So, Reference counter = 1, instruction is patched.
6. User unloads the kernel module.
# rmmod test-sdt.ko
Same function sequence as step 5 but this time filter_chain() will
return false because there are no consumer left. And thus
remove_breakpoint() will get called which will reset instruction and
decrement the counter.
So, Reference counter = 0, instruction is reset.
Does this explain your concerns?
Thanks,
Ravi
next prev parent reply other threads:[~2018-07-03 7:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 5:21 [PATCH v5 00/10] " Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 01/10] Uprobes: Move uprobe structure to uprobe.h Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 02/10] Uprobes: Simplify uprobe_register() body Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 03/10] Uprobe: Change set_swbp definition Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 04/10] Uprobe: Change set_orig_insn definition Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 05/10] Uprobe: Change uprobe_write_opcode definition Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 06/10] Uprobes: Support SDT markers having reference count (semaphore) Ravi Bangoria
2018-06-28 19:51 ` Oleg Nesterov
2018-06-29 3:23 ` Ravi Bangoria
2018-07-01 21:09 ` Oleg Nesterov
2018-07-02 5:16 ` Ravi Bangoria
2018-07-02 18:01 ` Oleg Nesterov
2018-07-03 5:30 ` Ravi Bangoria
2018-07-03 6:16 ` Srikar Dronamraju
2018-07-03 7:43 ` Ravi Bangoria [this message]
2018-07-04 9:16 ` Srikar Dronamraju
2018-07-04 9:24 ` Ravi Bangoria
2018-07-03 8:11 ` Ravi Bangoria
2018-07-03 16:36 ` Oleg Nesterov
2018-07-03 17:25 ` Oleg Nesterov
2018-07-04 4:53 ` Ravi Bangoria
2018-07-10 15:25 ` Oleg Nesterov
2018-07-11 8:44 ` Ravi Bangoria
2018-07-11 9:52 ` Ravi Bangoria
2018-07-12 14:58 ` Oleg Nesterov
2018-07-12 19:53 ` Song Liu
2018-07-13 7:55 ` Ravi Bangoria
2018-07-13 23:50 ` Song Liu
2018-07-16 8:20 ` Ravi Bangoria
2018-07-16 8:51 ` Ravi Bangoria
2018-07-13 5:39 ` Ravi Bangoria
2018-07-04 4:49 ` Ravi Bangoria
2018-07-03 17:12 ` Oleg Nesterov
2018-07-03 18:23 ` Oleg Nesterov
2018-07-04 5:25 ` Ravi Bangoria
2018-07-02 16:01 ` Srikar Dronamraju
2018-07-02 18:05 ` Oleg Nesterov
2018-07-03 6:29 ` Ravi Bangoria
2018-07-03 19:26 ` Oleg Nesterov
2018-07-04 5:26 ` Ravi Bangoria
2018-07-04 6:07 ` Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 07/10] trace_uprobe/sdt: Prevent multiple reference counter for same uprobe Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 08/10] Uprobes/sdt: " Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 09/10] Uprobes/sdt: Document about reference counter Ravi Bangoria
2018-07-02 14:54 ` Srikar Dronamraju
2018-07-03 7:50 ` Ravi Bangoria
2018-06-28 5:22 ` [PATCH v5 10/10] perf probe: Support SDT markers having reference counter (semaphore) Ravi Bangoria
2018-07-02 14:45 ` Srikar Dronamraju
2018-07-02 14:57 ` Srikar Dronamraju
2018-07-03 8:00 ` 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=c21db380-7dc0-2165-8616-8dcb519aa787@linux.ibm.com \
--to=ravi.bangoria@linux.ibm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexis.berlemont@gmail.com \
--cc=ananth@linux.vnet.ibm.com \
--cc=corbet@lwn.net \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux@armlinux.org.uk \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=oleg@redhat.com \
--cc=paul.burton@mips.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®