From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753057Ab1JGSdL (ORCPT ); Fri, 7 Oct 2011 14:33:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750747Ab1JGSdH (ORCPT ); Fri, 7 Oct 2011 14:33:07 -0400 Date: Fri, 7 Oct 2011 20:28:34 +0200 From: Oleg Nesterov To: Srikar Dronamraju Cc: Peter Zijlstra , Ingo Molnar , Steven Rostedt , Linux-mm , Arnaldo Carvalho de Melo , Linus Torvalds , Jonathan Corbet , Hugh Dickins , Christoph Hellwig , Masami Hiramatsu , Thomas Gleixner , Ananth N Mavinakayanahalli , Andrew Morton , Jim Keniston , Roland McGrath , Andi Kleen , LKML Subject: Re: [PATCH v5 3.1.0-rc4-tip 12/26] Uprobes: Handle breakpoint and Singlestep Message-ID: <20111007182834.GA1655@redhat.com> References: <20110920115938.25326.93059.sendpatchset@srdronam.in.ibm.com> <20110920120221.25326.74714.sendpatchset@srdronam.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110920120221.25326.74714.sendpatchset@srdronam.in.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/20, Srikar Dronamraju wrote: > > @@ -1285,6 +1286,9 @@ static struct task_struct *copy_process(unsigned long clone_flags, > INIT_LIST_HEAD(&p->pi_state_list); > p->pi_state_cache = NULL; > #endif > +#ifdef CONFIG_UPROBES > + p->utask = NULL; > +#endif I am not sure I understand this all right, but I am not sure this is enough... What if the forking task (current) is in UTASK_BP_HIT state? IOW, uprobe replaces the original syscall insn with "int3", then we enter the kernel from the xol_vma. The new child has the same modified instruction pointer (pointing to nowhere without CLONE_VM) and in any case it doesn't have TIF_SINGLESTEP. No? > +void uprobe_notify_resume(struct pt_regs *regs) > +{ > + struct vm_area_struct *vma; > + struct uprobe_task *utask; > + struct mm_struct *mm; > + struct uprobe *u = NULL; > + unsigned long probept; > + > + utask = current->utask; > + mm = current->mm; > + if (!utask || utask->state == UTASK_BP_HIT) { > + probept = get_uprobe_bkpt_addr(regs); > + down_read(&mm->mmap_sem); > + vma = find_vma(mm, probept); > + if (vma && valid_vma(vma)) > + u = find_uprobe(vma->vm_file->f_mapping->host, > + probept - vma->vm_start + > + (vma->vm_pgoff << PAGE_SHIFT)); > + up_read(&mm->mmap_sem); > + if (!u) > + /* No matching uprobe; signal SIGTRAP. */ > + goto cleanup_ret; > + if (!utask) { > + utask = add_utask(); > + /* Cannot Allocate; re-execute the instruction. */ > + if (!utask) > + goto cleanup_ret; > + } > + /* TODO Start queueing signals. */ > + utask->active_uprobe = u; > + handler_chain(u, regs); > + utask->state = UTASK_SSTEP; > + if (!pre_ssout(u, regs, probept)) > + user_enable_single_step(current); Oooh. Playing with user_*_single_step() is obviously not very nice... But I guess you have no choice. Although I _hope_ we can do something else later. And what if we step into a syscall insn? I do not understand this low level code, but it seems that in this case we trap in kernel mode and do_debug() doesn't clear X86_EFLAGS_TF because uprobes hook DIE_DEBUG. IOW, the task will trap again and again inside this syscall, no? > + } else if (utask->state == UTASK_SSTEP) { > + u = utask->active_uprobe; > + if (sstep_complete(u, regs)) { It is not clear to me if it is correct to simply return if sstep_complete() returns false... What if X86_EFLAGS_TF was "lost" somehow? Again, I am not saying I understand this magic. Not at all ;) Please simply ignore my email if you think everything is fine. Oleg.