Hi Oleg,
On Tue, 12 Nov 2013 17:00:01 +0900, Namhyung Kim wrote:
> For @+addr syntax: user-space uses relative symbol address from a loaded
>base address and kernel calculates the base address
>using "current->utask->vaddr - tu->offset".
I tried this
Hi Oleg,
On Tue, 12 Nov 2013 17:00:01 +0900, Namhyung Kim wrote:
For @+addr syntax: user-space uses relative symbol address from a loaded
base address and kernel calculates the base address
using current-utask-vaddr - tu-offset.
I tried this approach and
Hi Namhyung,
On 11/12, Namhyung Kim wrote:
>
> Let me clarify what I understand.
>
> For @addr syntax: kernel does no translation and uses given address
Yes,
> For @+addr syntax: user-space uses relative symbol address from a loaded
>base address and kernel calculates the
Hi Oleg and Masami,
On Sat, 9 Nov 2013 16:23:13 +0100, Oleg Nesterov wrote:
> On 11/09, Masami Hiramatsu wrote:
>>
>> In that case, I suggest you to use "@+addr" for the relative address,
>> since that is an offset, isn't that? :)
>
> Agreed, @+addr looks better!
Looks good to me too.
>
>> BTW,
Hi Oleg and Masami,
On Sat, 9 Nov 2013 16:23:13 +0100, Oleg Nesterov wrote:
On 11/09, Masami Hiramatsu wrote:
In that case, I suggest you to use @+addr for the relative address,
since that is an offset, isn't that? :)
Agreed, @+addr looks better!
Looks good to me too.
BTW, it seems that
Hi Namhyung,
On 11/12, Namhyung Kim wrote:
Let me clarify what I understand.
For @addr syntax: kernel does no translation and uses given address
Yes,
For @+addr syntax: user-space uses relative symbol address from a loaded
base address and kernel calculates the base
Hi Oleg,
On Fri, 8 Nov 2013 18:00:17 +0100, Oleg Nesterov wrote:
> On 11/07, Namhyung Kim wrote:
>>
>> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
>> >
>> > Note that instruction_pointer_set() is not really nice in any case,
>> > this can obviously confuse FETCH_MTD_reg("ip").
>>
>>
Hi Oleg,
On Fri, 8 Nov 2013 18:00:17 +0100, Oleg Nesterov wrote:
On 11/07, Namhyung Kim wrote:
On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
Note that instruction_pointer_set() is not really nice in any case,
this can obviously confuse FETCH_MTD_reg(ip).
Yes.
But lets
On 11/09, Masami Hiramatsu wrote:
>
> In that case, I suggest you to use "@+addr" for the relative address,
> since that is an offset, isn't that? :)
Agreed, @+addr looks better!
> BTW, it seems that @addr syntax is hard to use for uprobes, because
> current uprobes is based on a binary, not a
On 11/09, Masami Hiramatsu wrote:
In that case, I suggest you to use @+addr for the relative address,
since that is an offset, isn't that? :)
Agreed, @+addr looks better!
BTW, it seems that @addr syntax is hard to use for uprobes, because
current uprobes is based on a binary, not a process,
(2013/11/07 17:48), Namhyung Kim wrote:
> On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
>> On 11/06, Namhyung Kim wrote:
>>>
>>> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
>
> As for "-= tu->offset"... Can't we avoid it? User-space
On 11/07, Namhyung Kim wrote:
>
> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
> >
> > Note that instruction_pointer_set() is not really nice in any case,
> > this can obviously confuse FETCH_MTD_reg("ip").
>
> Yes.
>
> >
> > But lets ignore this. The solution is simple, we can pass/use
Hi Namhyung,
sorry for delay.
On 11/07, Namhyung Kim wrote:
>
> >> > As for "-= tu->offset"... Can't we avoid it? User-space needs to
> >> > calculate
> >> > the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Hmm.. it makes sense too. :)
> >
> > I am no longer sure ;)
>
Hi Namhyung,
sorry for delay.
On 11/07, Namhyung Kim wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to
calculate
the @ argument anyway, why it can't also substruct this offset?
Hmm.. it makes sense too. :)
I am no longer sure ;)
This way the @ argument
On 11/07, Namhyung Kim wrote:
On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
Note that instruction_pointer_set() is not really nice in any case,
this can obviously confuse FETCH_MTD_reg(ip).
Yes.
But lets ignore this. The solution is simple, we can pass/use this
info via
(2013/11/07 17:48), Namhyung Kim wrote:
On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
On 11/06, Namhyung Kim wrote:
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to calculate
the @
On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
> Forgot to mention,
>
> On 11/06, Oleg Nesterov wrote:
>>
>> I meant,
>>
>> saved_ip = instruction_pointer(regs);
>>
>> // pass the "ip" which was used to calculate
>> // the @addr argument to fetch_*()
On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
> On 11/06, Namhyung Kim wrote:
>>
>> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
>> > On 11/05, Oleg Nesterov wrote:
>> >>
>> >> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
>> >> the "@" argument
On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
On 11/06, Namhyung Kim wrote:
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to calculate
the @ argument anyway, why it can't also
On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
Forgot to mention,
On 11/06, Oleg Nesterov wrote:
I meant,
saved_ip = instruction_pointer(regs);
// pass the ip which was used to calculate
// the @addr argument to fetch_*() methods
Hi Oleg,
On Wed, 6 Nov 2013 17:28:06 +0100, Oleg Nesterov wrote:
> On 11/06, Namhyung Kim wrote:
>>
>> On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
>> > On 11/05, Namhyung Kim wrote:
>> >>
>> >> This is what I have for now:
>> >>
>> >> static void __user *get_user_vaddr(struct pt_regs
Forgot to mention,
On 11/06, Oleg Nesterov wrote:
>
> I meant,
>
> saved_ip = instruction_pointer(regs);
>
> // pass the "ip" which was used to calculate
> // the @addr argument to fetch_*() methods
>
> temp_ip = is_ret_probe(tu) ? func :
On 11/06, Namhyung Kim wrote:
>
> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
> > On 11/05, Oleg Nesterov wrote:
> >>
> >> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> >> the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Or
On 11/06, Namhyung Kim wrote:
>
> On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
> > On 11/05, Namhyung Kim wrote:
> >>
> >> This is what I have for now:
> >>
> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> >> addr,
> >> struct
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
> On 11/05, Oleg Nesterov wrote:
>>
>> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
>> the "@" argument anyway, why it can't also substruct this offset?
>>
>> Or perhaps we can change parse_probe_arg("@") to
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> This is what I have for now:
>>
>> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
>> struct trace_uprobe *tu)
>> {
>> unsigned long
On Tue, 5 Nov 2013 17:41:02 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
>> >>
>> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
>> >> addr)
>> >> {
>> >> return (void __force
On Tue, 5 Nov 2013 17:33:41 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
>> >
>> > So probably I was wrong and this all needs more thinking. Damn.
>>
>> :)
>
> Don't laugh at me ;)
:)
(And now I'm feeling guilty..)
>
Hi Oleg,
On Tue, 5 Nov 2013 17:28:20 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
>> > Or the syntax should be "name=probe @file/addr" or something like this.
>>
>> Okay. Let's call this kind of thing "cross-fetch" (or
Hi Oleg,
On Tue, 5 Nov 2013 17:28:20 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
Or the syntax should be name=probe @file/addr or something like this.
Okay. Let's call this kind of thing cross-fetch (or a better name
On Tue, 5 Nov 2013 17:33:41 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
So probably I was wrong and this all needs more thinking. Damn.
:)
Don't laugh at me ;)
:)
(And now I'm feeling guilty..)
Perhaps we really
On Tue, 5 Nov 2013 17:41:02 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr)
{
return (void __force __user *)addr +
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to calculate
the @ argument anyway, why it can't also substruct this offset?
Or perhaps we can change parse_probe_arg(@) to update param ? Yes,
On 11/06, Namhyung Kim wrote:
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr,
struct trace_uprobe *tu)
{
On 11/06, Namhyung Kim wrote:
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to calculate
the @ argument anyway, why it can't also substruct this offset?
Or perhaps we can change
Forgot to mention,
On 11/06, Oleg Nesterov wrote:
I meant,
saved_ip = instruction_pointer(regs);
// pass the ip which was used to calculate
// the @addr argument to fetch_*() methods
temp_ip = is_ret_probe(tu) ? func : saved_ip;
Hi Oleg,
On Wed, 6 Nov 2013 17:28:06 +0100, Oleg Nesterov wrote:
On 11/06, Namhyung Kim wrote:
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
On 11/05, Namhyung Kim wrote:
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
On 11/05, Oleg Nesterov wrote:
>
> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> the "@" argument anyway, why it can't also substruct this offset?
>
> Or perhaps we can change parse_probe_arg("@") to update "param" ? Yes,
> in this case it needs another argument, not
On 11/05, Namhyung Kim wrote:
>
> This is what I have for now:
>
> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
> struct trace_uprobe *tu)
> {
> unsigned long base_addr;
> unsigned long vaddr;
>
> base_addr =
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
> > Or the syntax should be "name=probe @file/addr" or something like this.
>
> Okay. Let's call this kind of thing "cross-fetch" (or a better name can
> be suggested).
Yes ;) and I am afraid there was some
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
> >
> > So probably I was wrong and this all needs more thinking. Damn.
>
> :)
Don't laugh at me ;)
> > Perhaps we really need to pass @file/offset, but it is not clear what
> > we can do with
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
> >>
> >>static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> >> addr)
> >>{
> >>return (void __force __user *)addr + instruction_pointer(regs);
> >>}
> >>
> >> ?
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr)
{
return (void __force __user *)addr + instruction_pointer(regs);
}
?
This should solve the
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
So probably I was wrong and this all needs more thinking. Damn.
:)
Don't laugh at me ;)
Perhaps we really need to pass @file/offset, but it is not clear what
we can do with bss/anon-mapping.
The
On 11/05, Namhyung Kim wrote:
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
Or the syntax should be name=probe @file/addr or something like this.
Okay. Let's call this kind of thing cross-fetch (or a better name can
be suggested).
Yes ;) and I am afraid there was some confusion
On 11/05, Namhyung Kim wrote:
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
unsigned long vaddr;
base_addr =
On 11/05, Oleg Nesterov wrote:
As for -= tu-offset... Can't we avoid it? User-space needs to calculate
the @ argument anyway, why it can't also substruct this offset?
Or perhaps we can change parse_probe_arg(@) to update param ? Yes,
in this case it needs another argument, not sure...
Or,
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
unsigned long vaddr;
base_addr = instruction_pointer(regs) - tu->offset;
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
> On 11/04, Oleg Nesterov wrote:
>>
>> On 11/04, Oleg Nesterov wrote:
>> >
>> > On 11/04, Oleg Nesterov wrote:
>> > >
>> > > But in any case, I strongly believe that it doesn't make any sense to
>> > > rely on tu->inode in get_user_vaddr().
On Mon, 4 Nov 2013 19:47:41 +0100, Oleg Nesterov wrote:
> On 11/04, Oleg Nesterov wrote:
>>
>> On 11/04, Oleg Nesterov wrote:
>> >
>> > But in any case, I strongly believe that it doesn't make any sense to
>> > rely on tu->inode in get_user_vaddr().
>>
>> Hmm. But I forgot about the case when you
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
> On 11/04, Oleg Nesterov wrote:
>>
>> But in any case, I strongly believe that it doesn't make any sense to
>> rely on tu->inode in get_user_vaddr().
>
> Hmm. But I forgot about the case when you probe the function in libc
> and want to dump
On Mon, 4 Nov 2013 16:51:31 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
>> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >> - this only allows to read the data from the same binary.
>> >
>> > Right. This is
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >
>> > This does not look right to me.
>> >
>> > - get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
>> > ->i_mmap_mutex.
On 11/04, Oleg Nesterov wrote:
>
> On 11/04, Oleg Nesterov wrote:
> >
> > On 11/04, Oleg Nesterov wrote:
> > >
> > > But in any case, I strongly believe that it doesn't make any sense to
> > > rely on tu->inode in get_user_vaddr().
> >
> > Hmm. But I forgot about the case when you probe the
On 11/04, Oleg Nesterov wrote:
>
> On 11/04, Oleg Nesterov wrote:
> >
> > But in any case, I strongly believe that it doesn't make any sense to
> > rely on tu->inode in get_user_vaddr().
>
> Hmm. But I forgot about the case when you probe the function in libc
> and want to dump the variable in
On 11/04, Oleg Nesterov wrote:
>
> But in any case, I strongly believe that it doesn't make any sense to
> rely on tu->inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the variable in libc...
So probably I was wrong and this all
On 11/04, Namhyung Kim wrote:
> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> >> - this only allows to read the data from the same binary.
> >
> > Right. This is also an unnecessary restriction. We should be able to
> >
On 11/04, Namhyung Kim wrote:
>
> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> >
> > This does not look right to me.
> >
> > - get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
> > ->i_mmap_mutex.
>
> Hmm.. yes, I think this is not needed. I guess it should
On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> - this only allows to read the data from the same binary.
>
> Right. This is also an unnecessary restriction. We should be able to
> access data in other binary.
Hmm.. I guess
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> Hello,
>
> Let me first apologize again if this was already discussed. And I also
> need to mention that I know almost nothing about elf/randomization/etc.
No no, this was not discussed enough. And I really appreciate your
thorough
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the variable in libc...
So probably I was wrong and this all needs
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the variable in libc...
So
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
On 11/04, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
This does not look right to me.
- get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
-i_mmap_mutex.
Hmm.. yes, I think
On Mon, 4 Nov 2013 16:51:31 +0100, Oleg Nesterov wrote:
On 11/04, Namhyung Kim wrote:
On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
- this only allows to read the data from the same binary.
Right. This is also an
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function in libc
and want to dump the
On Mon, 4 Nov 2013 19:47:41 +0100, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot about the case when you probe the function
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
On 11/04, Oleg Nesterov wrote:
But in any case, I strongly believe that it doesn't make any sense to
rely on tu-inode in get_user_vaddr().
Hmm. But I forgot
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
unsigned long vaddr;
base_addr = instruction_pointer(regs) - tu-offset;
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
Hello,
Let me first apologize again if this was already discussed. And I also
need to mention that I know almost nothing about elf/randomization/etc.
No no, this was not discussed enough. And I really appreciate your
thorough review! :)
On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
- this only allows to read the data from the same binary.
Right. This is also an unnecessary restriction. We should be able to
access data in other binary.
Hmm.. I guess this
On 11/04, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
This does not look right to me.
- get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
-i_mmap_mutex.
Hmm.. yes, I think this is not needed. I guess it should lookup a
proper
On 11/04, Namhyung Kim wrote:
On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
- this only allows to read the data from the same binary.
Right. This is also an unnecessary restriction. We should be able to
access data in
Hello,
Let me first apologize again if this was already discussed. And I also
need to mention that I know almost nothing about elf/randomization/etc.
However,
On 10/29, Namhyung Kim wrote:
>
> # nm foo | grep -e glob$ -e str -e foo
> 006008bc D foo
> 006008a8 D glob
>
Hello,
Let me first apologize again if this was already discussed. And I also
need to mention that I know almost nothing about elf/randomization/etc.
However,
On 10/29, Namhyung Kim wrote:
# nm foo | grep -e glob$ -e str -e foo
006008bc D foo
006008a8 D glob
(2013/10/29 15:53), Namhyung Kim wrote:
> Hello,
>
> This patchset implements memory (address), stack[N], deference,
> bitfield and retval (it needs uretprobe tho) fetch methods for
> uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
>
> Now kprobes and uprobes have their own
(2013/10/29 15:53), Namhyung Kim wrote:
Hello,
This patchset implements memory (address), stack[N], deference,
bitfield and retval (it needs uretprobe tho) fetch methods for
uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
Now kprobes and uprobes have their own
Hello,
This patchset implements memory (address), stack[N], deference,
bitfield and retval (it needs uretprobe tho) fetch methods for
uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
Now kprobes and uprobes have their own fetch_type_tables and, in turn,
memory and stack
Hello,
This patchset implements memory (address), stack[N], deference,
bitfield and retval (it needs uretprobe tho) fetch methods for
uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
Now kprobes and uprobes have their own fetch_type_tables and, in turn,
memory and stack
80 matches
Mail list logo
