mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®