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 <o...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
