(2013/03/19 5:57), Timo Juhani Lindfors wrote:
> Masami Hiramatsu writes:
>> Thank you for reporting!!
>
> Thanks for fixing these! I spent some time trying to automate the
> process of finding sensitive functions and eventually resorted into
> booting a kvm instance wit
st irq 25
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi Jason,
(2013/03/19 22:33), Jason Cooper wrote:
> On Tue, Mar 19, 2013 at 10:12:37PM +0900, Masami Hiramatsu wrote:
>> Hi,
>>
>> Here I've hit a bug on the recent kernel. As far as I know, this bug
>> exists on 3.9-rc1 too.
>>
>> When I
Hi Ezequiel,
(2013/03/19 22:39), Ezequiel Garcia wrote:
> Hi Masami,
>
> On Tue, Mar 19, 2013 at 10:12:37PM +0900, Masami Hiramatsu wrote:
>>
>> Here I've hit a bug on the recent kernel. As far as I know, this bug
>> exists on 3.9-rc1 too.
>>
>>
for it,
Hi Gregory,
Thank you for giving me the latest patch.
I've tested it on OpenBlocks-AX4 and that fixed the problem!
Tested-by: Masami Hiramatsu
Thanks,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail
(2013/03/21 20:39), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> (2013/03/19 5:57), Timo Juhani Lindfors wrote:
>>> Masami Hiramatsu writes:
>>>> Thank you for reporting!!
>>>
>>> Thanks for fixing these! I spent some time t
#x27;d like to ask Oskar
how the patch is going first.
Thank you,
>
> Cc: Ananth N Mavinakayanahalli
> Cc: Anil S Keshavamurthy
> Cc: "David S. Miller"
> Cc: Masami Hiramatsu
> Signed-off-by: Joonsoo Kim
> ---
> I fotgot to add lkml.
> Sorry for noi
(2013/04/02 21:16), oskar.and...@sonymobile.com wrote:
> On 12:49 Tue 02 Apr , Masami Hiramatsu wrote:
>> Hi,
>>
>> (2013/04/01 15:55), Joonsoo Kim wrote:
>>> Currently, initializing kprobe_blacklist is done during boot process.
>>> It takes 230
.
Other parts are good for me! :)
Thank you!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
(2013/04/03 17:28), oskar.and...@sonymobile.com wrote:
> Instead of using printk use pr_info/pr_err/pr_warn. This was
> detected by the checkpatch.pl script.
Thank you for cleaning this up ! :)
Acked-by: Masami Hiramatsu
>
> Signed-off-by: Oskar Andero
> ---
> ker
8 @@ int __kprobes register_kretprobe(struct kretprobe *rp)
> void *addr;
>
> if (kretprobe_blacklist_size) {
> + if (!kprobe_blacklist_initialized)
> + init_kprobe_blacklist();
Joonsoo reminds me that these calling points are not protecte
Currently, __kprobes is defined in linux/kprobes.h which
is too big to be included in small or basic headers
only for using this attribute.
This moves __kprobes definition into linux/compiler.h
in which other compiler attributes are defined.
Signed-off-by: Masami Hiramatsu
Cc: Timo Juhani
Note, this patch is for help to analyze what happened.
Signed-off-by: Masami Hiramatsu
Cc: Frank Ch. Eigler
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
---
arch/x86/kernel/kprobes/core.c |6 +-
1 file changed, 5 insertions(+), 1 deletio
Hi Ingo,
(2013/04/04 19:40), Masami Hiramatsu wrote:
> Currently, __kprobes is defined in linux/kprobes.h which
> is too big to be included in small or basic headers
> only for using this attribute.
>
> This moves __kprobes definition into linux/compiler.h
> in which other c
;> until the blacklist is first used.
>>
>> Cc: Masami Hiramatsu
>> Cc: David S. Miller
>> Reviewed-by: Radovan Lekanovic
>> Signed-off-by: Toby Collett
>> Signed-off-by: Oskar Andero
>> ---
>> kernel/kprobes.c | 98
>> ++
" local pointer to allocate and
initialize entries.
> @@ -151,7 +175,6 @@ static void init_kprobe_blacklist(void)
> kretprobe_blacklist[i].name);
> }
> }
> - kprobe_blacklist_initialized = 1;
And after initialized, assign black
e.c.
OK, it looks good for me. :)
Acked-by: Masami Hiramatsu
>
> Cc: Masami Hiramatsu
> Cc: David S. Miller
> Cc: linux-a...@vger.kernel.org
> Reviewed-by: Radovan Lekanovic
> Signed-off-by: Björn Davidsson
> Signed-off-by: Oskar Andero
> ---
> arch/x86/kernel/
t;
> Acked-by: Srikar Dronamraju
>
> Adding Masami in the Cc.
Thanks :), since the running context of uprobe handler is
different from kprobe one, this change is only needed for uprobe.
Acked-by: Masami Hiramatsu
Thank you,
>
>> ---
>> kernel/trace/trace_uprobe.c | 10 +++
ernel,
I think we'd better export __kprobe_text_* as macros of symbol strings
in kprobes.h, and reuse it.
Or, export such no-probe symbols via /sys/kernel/debug/kprobes/noprobe_syms
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Rese
that entire block within KPROBES_CAN_USE_FTRACE should be split
> out and go into update_kprobe_for_ftrace() or something similar.
>
> If that makes sense, I can send a patch to split out all the parts that
> modify anything in those two functions out of them.
I see, that makes sense :-)
(2013/01/29 4:49), Tejun Heo wrote:
> On Tue, Dec 25, 2012 at 12:51:37PM +0900, Masami Hiramatsu wrote:
>> (2012/12/22 10:57), Tejun Heo wrote:
>>> wait_for_kprobe_optimizer() seems largely broken. It uses
>>> optimizer_comp which is never re-initialized, so
>>&
k you can hook those
to set pre-filter option at first. Of course, since
those are universal options, we may need other per-event
pid filter.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.
: 8250_dw: Don't use UPF_FIXED_TYPE
966c4e39b5f7f249d7bb4c409176c9e6c5d48025
https://patchwork.kernel.org/patch/1958931/
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.c
(2013/02/28 20:34), Heikki Krogerus wrote:
> Hi,
>
> On Thu, Feb 28, 2013 at 08:13:30PM +0900, Masami Hiramatsu wrote:
>> Hi,
>>
>> I tried the latest "fixes" branch of arm-soc.git on OpenBlocks
>> AX3 (Marvel Armada-XP) and got below kernel panic in
(2013/03/12 17:16), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> Beacuse hash_64() is called from the get_kprobe() inside
>> int3 handler, kernel causes int3 recursion and crashes if
>> kprobes user puts a probe on it.
>>
>> Usually hash_64()
(2013/03/12 17:21), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> @@ -31,7 +32,7 @@
>> #error Wordsize not 32 or 64
>> #endif
>>
>> -static inline u64 hash_64(u64 val, unsigned int bits)
>> +static __kprobes inline u64 hash_64(u64 val, un
(2013/03/13 1:04), Linus Torvalds wrote:
> On Mon, Mar 11, 2013 at 7:22 AM, Masami Hiramatsu
> wrote:
>> Beacuse hash_64() is called from the get_kprobe() inside
>> int3 handler, kernel causes int3 recursion and crashes if
>> kprobes user puts a probe on it.
>>
&
(2013/03/13 22:28), Timo Juhani Lindfors wrote:
> Masami Hiramatsu writes:
>> OK, then I'll update it to just use __always_inline.
>
> I get a similar case of infinite recursion if I try to kprobe
> "inat_get_opcode_attribute":
Oops, right! And
patch uses __always_inline instead of inline to
prevent gcc from doing such things.
Changes in v2:
- Use __always_inline instead of using __kprobes
Signed-off-by: Masami Hiramatsu
Reported-by: Timo Juhani Lindfors
Cc: "David S. Miller"
Cc: Nadia Yvette Chambers
Cc: Pavel Emelyanov
Cc:
, since the copied instruction itself never be modified
on the buffer, it is needless to analyze the instruction every
probe hit.
To fix this issue, we checks it only once when registering probe
and store the result on ainsn->if_modifier.
Signed-off-by: Masami Hiramatsu
Reported-by: Timo Juh
e next instruction (even it will be the simplest one).
Instead, I think we can allow it on ftrace entries. Of course, ftrace side
change is also needed, e.g. sorting handlers for moving such ip-modifying
handler to the last.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. L
(2012/09/12 16:57), Hyeoncheol Lee wrote:
> Union members can be accessed with '.' or '->' like data structure
> member access
This seems good to me :)
Acked-by: Masami Hiramatsu
Thank you!
>
> Cc: Masami Hiramatsu
> Cc: Srikar Dronamraju
> Signed-
race_clock(void);
> extern u64 notrace trace_clock_global(void);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c38c81..92fb08e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -480,6 +480,7 @@ static struct {
> { trace_clock_local,"lo
ot;val" location start with 0xb0, which is same as
notify_die start address.
To avoid failing variable search at the function entry point,
this add a workaround which adjusts var-search address +5
only if all the below conditions are true;
- given variable is a formal_parameter
- the searc
(2012/10/03 21:27), Andi Kleen wrote:
> On Wed, Oct 03, 2012 at 09:17:07PM +0900, Masami Hiramatsu wrote:
>> Add a workaround for GCC -mfentry option. This enables perf
>> probe to find function parameters(arguments) at given function
>> entry point again.
>
> Could you
(2012/10/04 1:00), Mark Wielaard wrote:
> On Wed, 2012-10-03 at 09:53 -0400, Steven Rostedt wrote:
>> On Wed, 2012-10-03 at 21:17 +0900, Masami Hiramatsu wrote:
>>> <1><9a58>: Abbrev Number: 86 (DW_TAG_subprogram)
>>> <9a59> DW_A
ace.
I'd like to suggest that you can use djprobe-like solution here to eliminate
stop_machine.
The djprobe makes a bypass over that call instruction by using a kprobe,
and after replacing the call instruction, you can safely remove the bypass.
Here is an ols paper about djprobe.
http://www.k
nly called from inline assembly in the same file,
> mark it used and static.
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
It looks good to me.
Acked-by: Masami Hiramatsu <[EMAIL PROTECTED]>
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer
h strtok_r calls
> in order to parse a given string into its components.
> This is needed in Android since bionic does not support
> %as extension for sscanf.
OK, I've reviewed and tested, looks good! :)
Acked-by: Masami Hiramatsu
Thank you!
>
> Signed-off-by: Irina Tirde
(2012/09/20 18:40), Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> (2012/09/20 18:25), Ingo Molnar wrote:
>>>
>>> * Masami Hiramatsu wrote:
>>>
>>>> (2012/09/19 22:46), Borislav Petkov wrote:
>>>>> From: Borislav P
uffer and send_buf() and free_buf() can always be used.
Thanks!
This looks much nicer and simpler. I just have some comments below.
> Signed-off-by: Sjur Brændeland
> cc: Rusty Russell
> cc: Michael S. Tsirkin
> cc: Amit Shah
> cc: Linus Walleij
> cc: Masami Hiramatsu
> ---
S), $stack and $stackN
are also available. ;)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
es one redundant sg entry when nrbuf > 0,
>> but I think it is OK. (just a comment)
>
> I did this on purpose for the sake of simplicity, but I can
> change this to something like:
>alloc_size = sizeof(*buf) + sizeof(buf->sg) * max(nrbufs - 1, 1);
You wouldn&#x
e with a DEFINE_INSN_CACHE_OPS() macro
> which provides the alloc/free functions for each cache if needed.
> - move the struct kprobe_insn_cache to kprobe.h which allows to generate
> architecture specific insn slot caches outside of the core kprobes
> code.
>
Looks Good for
ea or within
> dma memory.
> Therefore add a mechanism which allows to specify an own allocator
> for an own insn slot cache.
>
Acked-by: Masami Hiramatsu
Thank you!
> Signed-off-by: Heiko Carstens
> ---
> include/linux/kprobes.h |2 ++
> kernel/kprobes.c|
t the easiest solution is
> to allocate an insn slot that is within the same 2GB area like the original
> instruction and patch the displacement field.
>
At least generic kprobes flow looks good for me.
Reviewed-by: Masami Hiramatsu
> Signed-off-by: Heiko Carstens
> ---
> arch/s
> accounting; later patches add additional 'trigger' flags and
> per-syscall triggers and filters.
>
This looks good for me.
Reviewed-by: Masami Hiramatsu
> Signed-off-by: Tom Zanussi
> ---
> kernel/trace/trace.h | 4 ++--
> kernel/trace/trace_
igger_ops;
> + trigger_data->cmd_ops = cmd_ops;
> + trigger_data->mode = cmd_ops->trigger_mode;
> + trigger_data->post_trigger = cmd_ops->post_trigger;
BTW, why the trigger_data has a copy of trigger_mode and post_trigger?
It seems redundant... :(
Also, the "
/*
>> * Use per cpu buffers for fastest access, but we might migrate
>> * So the mutex makes sure we have sole access to it.
>> */
>>
>> cpu = raw_smp_processor_id();
>> mutex = per_cpu(uprobe_cpu_mutex, cpu);
>> buf = per_cpu(uprobe_
Hi Tom,
I've reviewed and tested them and found no problem! ;)
So for this series:
Reviewed-by: Masami Hiramatsu
Now, I think it is the time to push it into tracing tree
and to be widely tested.
Thank you !
(2013/08/27 12:55), Tom Zanussi wrote:
> Hi,
>
> This is v7 of t
f->data = (void *)0;
> + }
No, the 'stack' means the address of the stack frame. Perhaps you might make a
new function to retrieve it from pt_regs.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hit
(2013/08/27 17:48), Namhyung Kim wrote:
> From: Namhyung Kim
>
> Implement uprobe-specific stack and memory fetch functions and add
> them to the uprobes_fetch_type_table. Other fetch fucntions will be
> shared with kprobes.
>
> Original-patch-by: Hyeoncheol Lee
> Cc
(2013/08/28 4:40), Tom Zanussi wrote:
> This is a repost of the v7 patchset - I inadvertently used the wrong
> branch in the previous posting, thought the branch URL was correct in
> both cases..
Ah, I directly pulled v7 from your git repository for test & review...
Thanks,
--
Mas
(2013/08/28 14:41), Namhyung Kim wrote:
> On Tue, 27 Aug 2013 20:54:45 +0900, Masami Hiramatsu wrote:
>> (2013/08/27 17:48), Namhyung Kim wrote:
>>> @@ -315,13 +316,18 @@ static int parse_probe_vars(char *arg, const struct
>>> fetch_type *t,
>>>
ement/Decrement etc of a per cpu variable
>>
>> DEFINE_PER_CPU(int, y);
>> __get_cpu_var(y)++
>>
>>Converts to
>>
>> this_cpu_inc(y)
>>
>>
>> Signed-off-by: Christoph Lameter
>>
>> Index: linux/include/linux/kprobe
Ping? :)
(2013/09/30 18:21), Masami Hiramatsu wrote:
> Fix to find the correct (as much as possible) line information
> for listing probes. Without this fix, perf probe --list action
> will show incorrect line information as below;
>
> # perf probe getname_flags
&g
t(tr) always ensures existance of tr in
trace_arrays, so above check is not needed in the case that
i_private directly points the tr.
Changes from V1:
- Use d_unhashed(f_dentry) to ensure the event exists according
to Oleg's comment.
Signed-off-by: Masami Hiramatsu
Suggested-by: Oleg Nest
.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7ed6976..a9a4fe5 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace
(2013/07/09 17:07), Peter Zijlstra wrote:
> On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
>> +if (wait) {
>> +/*
>> + * synchronize with kprobe_trace_func/kretprobe_trace_func
>> + * to ensure disabled (all ru
(2013/07/09 17:21), Peter Zijlstra wrote:
> On Tue, Jul 09, 2013 at 05:20:17PM +0900, Masami Hiramatsu wrote:
>> (2013/07/09 17:07), Peter Zijlstra wrote:
>>> On Tue, Jul 09, 2013 at 05:01:45PM +0900, Masami Hiramatsu wrote:
>>>> + if (wait) {
>>>> +
.
Changes in V2:
- Comment (in code) for clarify why we need to wait there.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_kprobe.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> then converts x86 jump label code to use it.
>
> If this is merged, I'll do a followup patch converting ftrace to use this
> infrastructure as well, as it's doing the same thing in principle already.
Hi Jiri,
Thank you for taking over it! :)
If yours is merged, I can move
op_machine
> would do, but only for a CPU which actually strays into the affected region.
Sounds a good idea :)
It may minimize the interface and the implementation will be
self-contained.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd.,
static struct notifier_block kprobe_exceptions_nb = {
> .notifier_call = kprobe_exceptions_notify,
> - .priority = 0x7fff /* we need to be notified first */
> + .priority = 0x7ff0 /* High priority, but not first. */
> };
>
> unsigned long __weak arch_deref_entry_po
t this code from others, since bp_* are
>> global.
>
> Caller is responsible for holding the text_mutex, so text_poke_bp() can't
> race with itself. And the proper consistency between text_poke_bp() and
> the notifier is achieved by the memory barriers.
Oops, right. I missed your
ode, but it should probably be separate.
Don't mind, kprobes optimization code prepares the destination code
buffer to jump in before code patching. Thus, we just need to give the
buffer address to text_poke_bp().
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
patched
> region, acting as "nop" has been there, in case we are doing nop -> jump
> and jump -> nop transitions).
>
> Ftrace has been using this very technique since 08d636b ("ftrace/x86:
> Have arch x86_64 use breakpoints instead of stop machine") for ages
ry->code + JUMP_LABEL_NOP_SIZE);
BTW, if the poker is NULL or text_poke_early, I think it doesn't need to
pass it to __jump_label_transform, does it?
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laborato
ng these patches, the "> kprobe_events" fails due to the
> event being busy.
>
> Masami, please review these patches and give your ack.
Steve, Oleg, could you also take a look on my additional 2 patches too?
I think both this series and my patches are required for
fixing most of
;
> + spin_lock(&lockcnt->lock);
> + return 0;
> +}
BTW, it looks that your dcache patch knows this and keeps double check for
the case of lockcnt->refcnt > 1 in dput().
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd.
Note structure */
> +struct sdt_note {
> + const char *name;
> + const char *provider;
> + union {
> + Elf64_Addr a64[3];
> + Elf32_Addr a32[3];
> + } addr;
> + struct sdt_note *next;
> +};
Hmm, could you use struct list
ed as a flag with existing --list and --add
> option?
>
Good catch! :)
No, that is really bad idea. All probes must be added by "--add" action.
So we need a new probe syntax for specifying sdt marker.
How about the below syntax?
[EVENT=]%PROVIDER:MARKER [ARG ...]
Of course, this w
the address of .stapsdt.base section too. And obviously this patch
> ignores any argument the SDT has which I think pretty important info.
> But we can add it later once the uprobes arg fetch patches are in.
Agreed, I'd like to see the argument support afterward.
Thanks!
--
Masa
(2013/09/04 15:49), Namhyung Kim wrote:
> On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote:
>> On 09/03/2013 02:47 PM, Masami Hiramatsu wrote:
>>> (2013/09/03 17:25), Ingo Molnar wrote:
>>>> * Hemant Kumar Shaw wrote:
>>>>
>>>>> This s
(2013/09/04 17:25), Mark Wielaard wrote:
> On Wed, 2013-09-04 at 15:49 +0900, Namhyung Kim wrote:
>> On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote:
>>> On 09/03/2013 02:47 PM, Masami Hiramatsu wrote:
>>>> Indeed, and also I'd like to know what versions of SDT
(2013/09/05 3:08), Hemant wrote:
> On 09/04/2013 02:09 PM, Masami Hiramatsu wrote:
>> (2013/09/04 17:25), Mark Wielaard wrote:
>>> On Wed, 2013-09-04 at 15:49 +0900, Namhyung Kim wrote:
>>>> On Tue, 03 Sep 2013 18:53:17 +0530, Hemant wrote:
>>>>> O
ll tracer based)
call-site uses rcu_read_lock_sched_notrace() instead of rcu_read_lock(),
in that case, I think we should use synchronize_sched(). is that wrong?
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hira
ist)
> + data->ops->func(data);
> + preempt_enable_notrace();
> +}
In this case, I think synchronize_sched() is correct. Of course,
we need to discuss why it needs to disable preempt here. :)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technolog
> - fixed small typos mentioned.
I've checked the above updates.
For this series:
Reviewed-by: Masami Hiramatsu
Thank you :)
>
> v8:
> - changed rcu_dereference_raw() to rcu_dereference() and moved
>synchronize_sched() out from under the syscall_trace_lock mutex.
>
essage.
$ ./perf probe -a %libm:slowexp_p6
Failed to open (null)
Error: Failed to add events. (-1)
I'll review each patch soon.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hi
if (nhdr.n_namesz == sizeof(SDT_NOTE_NAME) &&
> + !memcmp(data->d_buf + name_off, SDT_NOTE_NAME,
> + sizeof(SDT_NOTE_NAME))) {
> + tmp = populate_sdt_note(&elf, (const char *)
> +
}
What is this code for? params.sdt is true only if "--markers" is set, and that
should not be used with --add and --del, because it's an action "query markers".
We should give an error and abort here.
Other points are covered by Namhyung's review(thanks!).
Th
8 +262,13 @@ void __map_groups__fixup_end(struct map_groups *mg, enum
> map_type type);
> int show_available_markers(const char *module);
> int list_markers(const char *name);
> void cleanup_notes(struct sdt_note *start);
> +int probe_marker(const char *name, char *mark);
> +
the previous(?) SDT implementation also involves ugly semaphores.
Have that already gone?
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send
that the retval only can be used with uretprobes.
Look good for me :)
Acked-by: Masami Hiramatsu
Thank you!
>
> Original-patch-by: Hyeoncheol Lee
> Cc: Masami Hiramatsu
> Cc: Srikar Dronamraju
> Cc: Oleg Nesterov
> Cc: zhangwei(Jovi)
> Cc: Arnaldo Carvalho
a_size() and store_trace_args() to reduce
> code duplication.
>
> Cc: Masami Hiramatsu
> Cc: Srikar Dronamraju
> Cc: Oleg Nesterov
> Cc: zhangwei(Jovi)
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Namhyung Kim
> ---
> kernel/trace/trace_uprobe.c | 97
>
soon.
Thank you,
(2013/09/26 0:38), Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 25, 2013 at 10:16:16PM +0900, Masami Hiramatsu escreveu:
>> Fix perf probe to probe on some symbols which have some
>> optimzation suffixes, e.g. ".part", ".isra", and ".const
)
probe:getname_flags_2 (on user_path_at_empty:4@ksrc/linux-3/fs/namei.c)
Signed-off-by: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
tools/perf/util/dwarf-aux.c| 21 -
tools/perf/util/dwarf-aux.h|6 -
tools
(2013/09/30 14:08), Namhyung Kim wrote:
> Hi Masami,
>
> Just a nitpick.
>
> On Fri, 27 Sep 2013 15:57:07 +0900, Masami Hiramatsu wrote:
>> /**
>> + * die_find_inlinefunc_next - Search an inlined function at given address
>> + * @cu_die: a CU DIE which inc
)
probe:getname_flags_2 (on user_path_at_empty:4@ksrc/linux-3/fs/namei.c)
Changes at v2:
- Fix typos in the function comments. (Thanks to Namhyung Kim)
- Use die_find_top_inlinefunc instead of die_find_inlinefunc_next.
Signed-off-by: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
(2013/09/15 20:28), Hemant wrote:
> Hi Masami,
Hi, and sorry for replying so late. I missed this in my mailbox.
> On 09/04/2013 01:31 PM, Masami Hiramatsu wrote:
>> (2013/09/04 15:42), Namhyung Kim wrote:
>>> On Tue, 03 Sep 2013 13:06:55 +0530, Hemant Kumar wrote:
>>
; perf probe %foo:bar
Right,
> And, once, the argument support is enabled (all the arguments will be
> fetched at the marker location), we can go with:
> perf probe %foo:bar $args
Correct ;). In my plan, $parms and $vars will be also introduced for
accessing all function parameters and l
ab when a probe point is found.
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: Masami Hiramatsu
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-finder.c | 77 +---
tools/perf/util/probe-finde
hange
Current kprobe_ftrace_handler expects ip == regs.ip, but
it's not correct on x86-64 (and now on x86 too). This should
be fixed.
- Use regs.ip for return address on ftrace
From Steven, this change is suggested. Thanks!
Thank you,
---
Masami Hiramatsu (3):
[BUGFIX] kprobes/x
Adjust x86 regs.ip to ip + MCOUNT_INSN_SIZE as like as
on x86-64. This helps us to consolidate codes which use
regs->ip on both of x86/x86-64.
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
---
arch/x86/kernel/entr
Current kprobe_ftrace_handler expects regs->ip == ip, but it is
incorrect (originally on x86-64). Actually, ftrace handler sets
regs->ip = ip + MCOUNT_INSN_SIZE.
kprobe_ftrace_handler must take care for that.
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: &qu
From: Steven Rostedt
Allow ftrace handlers to change RIP register (regs->ip)
in handlers. This will allow handlers to call another
function instead of original function.
Signed-off-by: Steven Rostedt
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Pet
ing to modify regs->ip and kprobes breakpoint
handler also allows to skip singlestepping because there
is a ftrace call (not an original instruction).
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
---
a
(2012/09/05 23:31), Masami Hiramatsu wrote:
> Fix kprobes/x86 to support jprobes on ftrace-based kprobes.
> Because of -mfentry support of ftrace, ftrace is now put
> on the beginning of function where jprobes are put.
>
> Originally ftrace-based kprobes doesn't support jpro
(2012/10/17 17:28), Hyeoncheol Lee wrote:
> The function allocated wrong size buffers for names
>
> Cc: Masami Hiramatsu
> Cc: Srikar Dronamraju
> Signed-off-by: Hyeoncheol Lee
> ---
> tools/perf/util/probe-event.c | 11 +++
> 1 file changed, 7 in
1 - 100 of 6170 matches
Mail list logo
