From: Peter Zijlstra <peterz@infradead.org> To: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>, Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Ananth N Mavinakayanahalli <ananth@in.ibm.com>, Jim Keniston <jkenisto@linux.vnet.ibm.com>, LKML <linux-kernel@vger.kernel.org>, Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>, Christoph Hellwig <hch@infradead.org>, Steven Rostedt <rostedt@goodmis.org>, Arnaldo Carvalho de Melo <acme@infradead.org>, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>, Thomas Gleixner <tglx@linutronix.de>, Anton Arapov <anton@redhat.com> Subject: Re: [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Date: Mon, 23 Apr 2012 21:18:10 +0200 [thread overview] Message-ID: <1335208690.2463.84.camel@laptop> (raw) In-Reply-To: <20120423172957.GA29708@redhat.com> On Mon, 2012-04-23 at 19:29 +0200, Oleg Nesterov wrote: > On 04/23, Peter Zijlstra wrote: > > > > On Mon, 2012-04-23 at 12:54 +0530, Srikar Dronamraju wrote: > > > * Peter Zijlstra <peterz@infradead.org> [2012-04-23 09:14:00]: > > > > > > > On Fri, 2012-04-20 at 20:37 +0200, Oleg Nesterov wrote: > > > > > Say, a user wants to probe /sbin/init only. What if init forks? > > > > > We should remove breakpoints from child->mm somehow. > > > > > > > > How is that hard? dup_mmap() only copies the VMAs, this doesn't actually > > > > copy the breakpoint. So the child doesn't have a breakpoint to be > > > > removed. > > > > > > > > > > Because the pages are COWED, the breakpoint gets copied over to the > > > child. If we dont want the breakpoints to be not visible to the child, > > > then we would have to remove them explicitly based on the filter (i.e if > > > and if we had inserted breakpoints conditionally based on filter). > > > > I thought we didn't COW shared maps since the fault handler will fill in > > the pages right and only anon stuff gets copied. > > Confused... > > Do you mean the "Don't copy ptes where a page fault will fill them correctly" > check in copy_page_range() ? Yes, but this vma should have ->anon_vma != NULL > if it has the breakpoint installed by uprobes. Oh, argh yeah, we add an anon_vma there.. > > > Once we add the conditional breakpoint insertion (which is tricky), > > > > How so? > > I agree with Srikar this doesn't look simple to me. First of all, > currently it is not easy to find the tasks which use this ->mm. > OK, we can simply do for_each_process() under tasklist, but this is > not very nice. > > But again, to me this is not the main problem. CLONE_VM without CLONE_THREAD is the problem, right? Can we get away with not supporting that, at least initially? > > > Conditional removal > > > of breakpoints in fork path would just be an extension of the > > > conditional breakpoint insertion. > > > > Right, I don't think that removal is particularly hard if needed. > > I agree that remove_breakpoint() itself is not that hard, probably. > > But the whole idea of filtering is not clear to me. I mean, when/how > we should call the filter, and what should be the argument. > task_struct? Probably, but I am not sure. Well, the idea is really very simple: if for a probe an {mm,tasks} set has all negative filters we do not install the probe on that mm. The filters already take a uprobe_consumer and task_struct as argument. > And btw fork()->dup_mmap() should call the filter too. Suppose that > uprobe_consumer wants to trace the task T and its children, this looks > very natural. Agreed. > And we need to rework uprobe_register(). It can't simply return if > this (inode, offset) already has the consumer. Not quite sure what you mean. uprobe_register() doesn't have such a return value. It returns 0 on success and an error otherwise. Do you mean __uprobe_register() ? That calls register_for_each_vma() and that can simply call ->filter() for each vma it iterates. In fact, it can get away with only calling the filter for the new consumer. > So far I think this needs more thinking. And imho we should merge the > working code Srikar already has, then try to add this (agreed, very > important) optimization. Sure..
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org> To: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>, Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Ananth N Mavinakayanahalli <ananth@in.ibm.com>, Jim Keniston <jkenisto@linux.vnet.ibm.com>, LKML <linux-kernel@vger.kernel.org>, Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>, Christoph Hellwig <hch@infradead.org>, Steven Rostedt <rostedt@goodmis.org>, Arnaldo Carvalho de Melo <acme@infradead.org>, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>, Thomas Gleixner <tglx@linutronix.de>, Anton Arapov <anton@redhat.com> Subject: Re: [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Date: Mon, 23 Apr 2012 21:18:10 +0200 [thread overview] Message-ID: <1335208690.2463.84.camel@laptop> (raw) In-Reply-To: <20120423172957.GA29708@redhat.com> On Mon, 2012-04-23 at 19:29 +0200, Oleg Nesterov wrote: > On 04/23, Peter Zijlstra wrote: > > > > On Mon, 2012-04-23 at 12:54 +0530, Srikar Dronamraju wrote: > > > * Peter Zijlstra <peterz@infradead.org> [2012-04-23 09:14:00]: > > > > > > > On Fri, 2012-04-20 at 20:37 +0200, Oleg Nesterov wrote: > > > > > Say, a user wants to probe /sbin/init only. What if init forks? > > > > > We should remove breakpoints from child->mm somehow. > > > > > > > > How is that hard? dup_mmap() only copies the VMAs, this doesn't actually > > > > copy the breakpoint. So the child doesn't have a breakpoint to be > > > > removed. > > > > > > > > > > Because the pages are COWED, the breakpoint gets copied over to the > > > child. If we dont want the breakpoints to be not visible to the child, > > > then we would have to remove them explicitly based on the filter (i.e if > > > and if we had inserted breakpoints conditionally based on filter). > > > > I thought we didn't COW shared maps since the fault handler will fill in > > the pages right and only anon stuff gets copied. > > Confused... > > Do you mean the "Don't copy ptes where a page fault will fill them correctly" > check in copy_page_range() ? Yes, but this vma should have ->anon_vma != NULL > if it has the breakpoint installed by uprobes. Oh, argh yeah, we add an anon_vma there.. > > > Once we add the conditional breakpoint insertion (which is tricky), > > > > How so? > > I agree with Srikar this doesn't look simple to me. First of all, > currently it is not easy to find the tasks which use this ->mm. > OK, we can simply do for_each_process() under tasklist, but this is > not very nice. > > But again, to me this is not the main problem. CLONE_VM without CLONE_THREAD is the problem, right? Can we get away with not supporting that, at least initially? > > > Conditional removal > > > of breakpoints in fork path would just be an extension of the > > > conditional breakpoint insertion. > > > > Right, I don't think that removal is particularly hard if needed. > > I agree that remove_breakpoint() itself is not that hard, probably. > > But the whole idea of filtering is not clear to me. I mean, when/how > we should call the filter, and what should be the argument. > task_struct? Probably, but I am not sure. Well, the idea is really very simple: if for a probe an {mm,tasks} set has all negative filters we do not install the probe on that mm. The filters already take a uprobe_consumer and task_struct as argument. > And btw fork()->dup_mmap() should call the filter too. Suppose that > uprobe_consumer wants to trace the task T and its children, this looks > very natural. Agreed. > And we need to rework uprobe_register(). It can't simply return if > this (inode, offset) already has the consumer. Not quite sure what you mean. uprobe_register() doesn't have such a return value. It returns 0 on success and an error otherwise. Do you mean __uprobe_register() ? That calls register_for_each_vma() and that can simply call ->filter() for each vma it iterates. In fact, it can get away with only calling the filter for the new consumer. > So far I think this needs more thinking. And imho we should merge the > working code Srikar already has, then try to add this (agreed, very > important) optimization. Sure.. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. 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@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-04-23 19:18 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-05 22:20 [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Oleg Nesterov 2012-04-05 22:20 ` Oleg Nesterov 2012-04-05 22:20 ` [PATCH 1/6] uprobes: introduce find_active_uprobe() Oleg Nesterov 2012-04-05 22:20 ` Oleg Nesterov 2012-04-05 22:21 ` [PATCH 2/6] uprobes: introduce is_swbp_at_addr_fast() Oleg Nesterov 2012-04-05 22:21 ` Oleg Nesterov 2012-04-16 10:08 ` Peter Zijlstra 2012-04-16 10:08 ` Peter Zijlstra 2012-04-16 14:44 ` Oleg Nesterov 2012-04-16 14:44 ` Oleg Nesterov 2012-04-16 14:55 ` Peter Zijlstra 2012-04-16 14:55 ` Peter Zijlstra 2012-04-16 15:34 ` Oleg Nesterov 2012-04-16 15:34 ` Oleg Nesterov 2012-04-17 10:08 ` Peter Zijlstra 2012-04-17 10:08 ` Peter Zijlstra 2012-04-17 17:09 ` Oleg Nesterov 2012-04-17 17:09 ` Oleg Nesterov 2012-04-17 19:53 ` Peter Zijlstra 2012-04-17 19:53 ` Peter Zijlstra 2012-04-05 22:21 ` [PATCH 3/6] uprobes: teach find_active_uprobe() to provide the "is_swbp" info Oleg Nesterov 2012-04-05 22:21 ` Oleg Nesterov 2012-04-05 22:21 ` [PATCH 4/6] uprobes: change register_for_each_vma() to take mm->mmap_sem for writing Oleg Nesterov 2012-04-05 22:21 ` Oleg Nesterov 2012-04-05 22:22 ` [PATCH 5/6] uprobes: teach handle_swbp() to rely on "is_swbp" rather than uprobes_srcu Oleg Nesterov 2012-04-05 22:22 ` Oleg Nesterov 2012-04-05 22:22 ` [PATCH 6/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Oleg Nesterov 2012-04-05 22:22 ` Oleg Nesterov 2012-04-14 11:16 ` [RFC 0/6] " Ingo Molnar 2012-04-14 11:16 ` Ingo Molnar 2012-04-16 11:31 ` Srikar Dronamraju 2012-04-16 11:31 ` Srikar Dronamraju 2012-04-16 14:41 ` Oleg Nesterov 2012-04-16 14:41 ` Oleg Nesterov 2012-04-25 12:52 ` Srikar Dronamraju 2012-04-25 12:52 ` Srikar Dronamraju 2012-04-25 14:22 ` Oleg Nesterov 2012-04-25 14:22 ` Oleg Nesterov 2012-04-14 13:16 ` Peter Zijlstra 2012-04-14 13:16 ` Peter Zijlstra 2012-04-14 20:52 ` Oleg Nesterov 2012-04-14 20:52 ` Oleg Nesterov 2012-04-15 10:51 ` Peter Zijlstra 2012-04-15 10:51 ` Peter Zijlstra 2012-04-15 19:53 ` Oleg Nesterov 2012-04-15 19:53 ` Oleg Nesterov 2012-04-15 21:48 ` Peter Zijlstra 2012-04-15 21:48 ` Peter Zijlstra 2012-04-15 23:44 ` Oleg Nesterov 2012-04-15 23:44 ` Oleg Nesterov 2012-04-16 10:16 ` Peter Zijlstra 2012-04-16 10:16 ` Peter Zijlstra 2012-04-16 21:47 ` Oleg Nesterov 2012-04-16 21:47 ` Oleg Nesterov 2012-04-20 10:14 ` Peter Zijlstra 2012-04-20 10:14 ` Peter Zijlstra 2012-04-20 10:16 ` Srikar Dronamraju 2012-04-20 10:16 ` Srikar Dronamraju 2012-04-20 18:58 ` Oleg Nesterov 2012-04-20 18:58 ` Oleg Nesterov 2012-04-20 18:37 ` Oleg Nesterov 2012-04-20 18:37 ` Oleg Nesterov 2012-04-23 7:14 ` Peter Zijlstra 2012-04-23 7:14 ` Peter Zijlstra 2012-04-23 7:24 ` Srikar Dronamraju 2012-04-23 7:24 ` Srikar Dronamraju 2012-04-23 7:40 ` Peter Zijlstra 2012-04-23 7:40 ` Peter Zijlstra 2012-04-23 17:29 ` Oleg Nesterov 2012-04-23 17:29 ` Oleg Nesterov 2012-04-23 19:18 ` Peter Zijlstra [this message] 2012-04-23 19:18 ` Peter Zijlstra 2012-04-23 20:50 ` Oleg Nesterov 2012-04-23 20:50 ` Oleg Nesterov 2012-04-23 21:25 ` Oleg Nesterov 2012-04-23 21:25 ` Oleg Nesterov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1335208690.2463.84.camel@laptop \ --to=peterz@infradead.org \ --cc=acme@infradead.org \ --cc=akpm@linux-foundation.org \ --cc=ananth@in.ibm.com \ --cc=andi@firstfloor.org \ --cc=anton@redhat.com \ --cc=hch@infradead.org \ --cc=jkenisto@linux.vnet.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mingo@elte.hu \ --cc=oleg@redhat.com \ --cc=rostedt@goodmis.org \ --cc=srikar@linux.vnet.ibm.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.