Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)

[Namhyung Kim]

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 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 more thinking. Damn.
>> > Perhaps we really need to pass @file/offset, but it is not clear what
>> > we can do with bss/anon-mapping.
>>
>> Or. Not that I really like this, but just for discussion...
>>
>> How about
>>
>> 	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 problems with relocations/randomization/bss.
>>
>> The obvious disadvantage is that it is not easy to calculate the
>> offset we need to pass as an argument, it depends on the probed
>> function.
>
> forgot to mention... and instruction_pointer() can't work in ret-probe,
> we need to pass the "unsigned long func" arg somehow...

Hmm.. what's the value of tu->offset in this case?  Does it have the
offset of the return address or the start of the function?

Anyway, what we really need is the base address of the text mapping
IMHO.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/