On Fri, Apr 11, 2014 at 05:22:07PM +0200, Oleg Nesterov wrote:
On 04/11, Oleg Nesterov wrote:
Can't we do _something_ like below?
If not, I'd propose the patch below.
I can be easily wrong, but it seems that arch/arm can reimplement arch_uprobe_flush_xol_icache() and do flush_ptrace_access()-like code. It needs kaddr, but this is not a problem.
Btw. From arch/arm/include/asm/cacheflush.h
#define flush_icache_user_range(vma,page,addr,len) \ flush_dcache_page(page)
but it has no users?
I wonder whether you've read this yet:
http://lkml.iu.edu//hypermail/linux/kernel/1404.1/00725.html
where I proposed removing flush_icache_user_range() since it's not used on a great many architectures.
And I am just curious, why arm's copy_to_user_page() disables premption before memcpy?
flush_ptrace_access() needs to run on the CPU which ended up with the dirty cache line(s) to cope with those which do not have hardware broadcasting of cache maintanence operations.
This is why the hacks that you're doing are just that - they're hacks and are all broken in some way.
So, let me re-quote what I asked in a previous thread:
| Given that we've already solved that problem, wouldn't it be a good idea | if the tracing code would stop trying to reinvent broken solutions to | problems we have already solved?
I fail to see what your problem is with keeping the vma around, and using that infrastructure. If it needs optimisation for uprobes, then let's optimise it. Let's not go inventing a whole new interface solving the same problem.