From: Oleg Nesterov <oleg@redhat.com> To: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>, Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: 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: [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Date: Fri, 6 Apr 2012 00:20:24 +0200 [thread overview] Message-ID: <20120405222024.GA19154@redhat.com> (raw) Hello. Not for inclusion yet, only for the early review. I didn't even try to test these changes, and I am not expert in this area. And even _if_ this code is correct, I need to re-split these changes anyway, update the changelogs, etc. Questions: - does it make sense? - can it work or I missed something "in general" ? Why: - It would be nice to remove a member from task_struct. - Afaics, the usage of uprobes_srcu does not look right, at least in theory, see 6/6. The comment above delete_uprobe() says: The current unregistering thread waits till all other threads have hit a breakpoint, to acquire the uprobes_treelock before the uprobe is removed from the rbtree. but synchronize_srcu() can only help if a thread which have hit the breakpoint has already called srcu_read_lock(). It can't synchronize with read_lock "in future", and there is a small window. We could probably add another synchronize_sched() before synchronize_srcu(), but this doesn't look very nice and - I am not sure yet, but perhaps with these changes we can also kill mm->uprobes_state.count. Any review is very much appreciated. Oleg. include/linux/sched.h | 1 - kernel/events/uprobes.c | 117 ++++++++++++++++++++++++++++++----------------- 2 files changed, 75 insertions(+), 43 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com> To: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>, Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: 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: [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id Date: Fri, 6 Apr 2012 00:20:24 +0200 [thread overview] Message-ID: <20120405222024.GA19154@redhat.com> (raw) Hello. Not for inclusion yet, only for the early review. I didn't even try to test these changes, and I am not expert in this area. And even _if_ this code is correct, I need to re-split these changes anyway, update the changelogs, etc. Questions: - does it make sense? - can it work or I missed something "in general" ? Why: - It would be nice to remove a member from task_struct. - Afaics, the usage of uprobes_srcu does not look right, at least in theory, see 6/6. The comment above delete_uprobe() says: The current unregistering thread waits till all other threads have hit a breakpoint, to acquire the uprobes_treelock before the uprobe is removed from the rbtree. but synchronize_srcu() can only help if a thread which have hit the breakpoint has already called srcu_read_lock(). It can't synchronize with read_lock "in future", and there is a small window. We could probably add another synchronize_sched() before synchronize_srcu(), but this doesn't look very nice and - I am not sure yet, but perhaps with these changes we can also kill mm->uprobes_state.count. Any review is very much appreciated. Oleg. include/linux/sched.h | 1 - kernel/events/uprobes.c | 117 ++++++++++++++++++++++++++++++----------------- 2 files changed, 75 insertions(+), 43 deletions(-) -- 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 reply other threads:[~2012-04-05 22:21 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-05 22:20 Oleg Nesterov [this message] 2012-04-05 22:20 ` [RFC 0/6] uprobes: kill uprobes_srcu/uprobe_srcu_id 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 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=20120405222024.GA19154@redhat.com \ --to=oleg@redhat.com \ --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=peterz@infradead.org \ --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.