Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754720Ab1GABWQ (ORCPT ); Thu, 30 Jun 2011 21:22:16 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]:49646 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753670Ab1GABWO (ORCPT ); Thu, 30 Jun 2011 21:22:14 -0400 X-AuditID: b753bd60-a467eba0000050a4-13-4e0d214356c2 X-AuditID: b753bd60-a467eba0000050a4-13-4e0d214356c2 Message-ID: <4E0D2141.4080608@hitachi.com> Date: Fri, 01 Jul 2011 10:22:09 +0900 From: Masami Hiramatsu Organization: Systems Development Lab., Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Zijlstra Cc: Steven Rostedt , LKML , Frederic Weisbecker , Thomas Gleixner , Ingo Molnar , Andrew Morton , yrl.pp-manager.tt@hitachi.com Subject: Re: [RFC][PATCH] kprobes: Add separate preempt_disabling for kprobes References: <1309440213.26417.76.camel@gandalf.stny.rr.com> <1309449117.26417.90.camel@gandalf.stny.rr.com> <1309470997.12449.614.camel@twins> In-Reply-To: <1309470997.12449.614.camel@twins> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1322 Lines: 35 (2011/07/01 6:56), Peter Zijlstra wrote: > On Thu, 2011-06-30 at 11:51 -0400, Steven Rostedt wrote: >> >> To solve this, I've added a per_cpu variable called >> kprobe_preempt_disabled, that is set by the kprobe code. If it is set, >> the preempt_schedule() will not preempt the code. Sorry for replying so late :( > Damn this is ugly. Can we step back and see if we can make the > requirement for kprobe to disable preemption go away? As I replied right now, I think we can just eliminate that disabling preemption code. At least we'd better try it. I agree with you, introducing this kind of complexity just for kprobes is not what I want. :( > Why does it have to do that anyway? Isn't it keeping enough per-task > state to allow preemption over the single step? preemption itself must not happen on single stepping, but it seems impossible to do heavy context switching with setting TF bit... Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/