On 04/15, Peter Zijlstra wrote: > > On Sat, 2012-04-14 at 22:52 +0200, Oleg Nesterov wrote: > > > > - can it work or I missed something "in general" ? > > > > > > So we insert in the rb-tree before we take mmap_sem, this means we can > > > hit a non-uprobe int3 and still find a uprobe there, no? > > > > Yes, but unless I miss something this is "off-topic", this > > can happen with or without these changes. If find_uprobe() > > succeeds we assume that this bp was inserted by uprobe. > > OK, but then I completely missed what the point of that > down_write() stuff is.. To ensure handle_swbp() can't race with unregister + register and send the wrong SIGTRAP. handle_swbp() roughly does under down_read(mmap_sem) if (find_uprobe(vaddr)) process_uprobe(); else if (is_swbp_at_addr_fast(vaddr)) // non-uprobe int3 send_sig(SIGTRAP); else restart_insn(vaddr); // raced with unregister note that is_swbp_at_addr_fast() is used (currently) to detect the race with upbrobe_unregister() and that is why we can remove uprobes_srcu. But if find_uprobe() fails, there is a window before is_swbp_at_addr_fast() reads the memory. Suppose that the next uprobe_register() inserts the new uprobe at the same address. In this case the task will be wrongly killed. Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>