Messages in this thread | | | Date | Wed, 4 Dec 2013 12:30:24 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH?] uprobes: change uprobe_write_opcode() to modify the page directly |
| |
On 12/03, H. Peter Anvin wrote: > > On 12/03/2013 02:01 PM, Linus Torvalds wrote: > > On Tue, Dec 3, 2013 at 12:54 PM, Oleg Nesterov <oleg@redhat.com> wrote: > >> > >> So do you think the patch I sent is wrong? Why? > > > > I think the TLB shootdown should guarantee that it's ok on other > > CPU's, since that's basically what we do on mmap. > > > > I think that is true for other CPUs; however, there are definitely CPUs > out there (which Linux supports) for which you have to synchronize the I > and D sides "manually" after writing code through memory, at least > through the CPU. That is at least one reason why MIPS has a > cacheflush() system call, for example.
OK, probably (with or without the patch I sent) uprobe_write_opcode() needs flush_icache_page(). Altough it is nop on x86 and powerpc (architectures we currently support).
But I still can't understand your "There is no architecture-independent way to make code globally visible". If this is true, then how, say, do_swap_page() can work?
So I still think the patch should work (I'll add flush_icache_page).
> > But looking closer at this, I think I see why the old code did what it > > did. I think it's breaking shared mmap pages on purpose rather than > > dirtying them. Which is probably the right thing to do. > > In other words, treating them as MAP_PRIVATE? Wouldn't it be better to > throw an error if we can't honor the semantics of the mapping that we > are using?
Yes, uprobes never writes to MAP_SHARED vmas.
Oleg.
| |