public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vara Prasad <prasadav@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	prasanna@in.ibm.com, davem@davemloft.net,
	systemtap@sources.redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [1/6 PATCH] Kprobes : Prevent possible race conditions generic changes
Date: Thu, 07 Jul 2005 14:20:40 -0700	[thread overview]
Message-ID: <42CD9CA8.5080807@us.ibm.com> (raw)
In-Reply-To: <20050707103421.GU21330@wotan.suse.de>

Andi Kleen wrote:

>On Thu, Jul 07, 2005 at 03:25:37AM -0700, Andrew Morton wrote:
>  
>
>>Prasanna S Panchamukhi <prasanna@in.ibm.com> wrote:
>>    
>>
>>>There are possible race conditions if probes are placed on routines within the
>>>kprobes files and routines used by the kprobes.
>>>      
>>>
>>So...  don't do that then?  Is it likely that anyone would want to stick a
>>probe on the kprobe code itself?
>>    
>>
>
>iirc one goal of systemtap (which uses kprobes) is to be provable
>safe so that an user cannot crash the kernel by adding probes. Basically
>to make it possible to use this on production systems safely. I have my
>doubts they will fully reach it, but at least it's a nice goal.
>  
>
Yes, you are right it is a lofty goal but we feel we can achieve this 
with safety features built into the system. To facilitate this we are 
providing two modes safe and guru. In safe mode we are trying to limit 
the user to do limited yet useful operations so that they don't 
compromise the integrity of the system. Guru mode is meant for power 
users where we expect the users to know what they are doing hence they 
can do more intrusive operations. Another feature we are doing is coming 
up with a library of routines for common needs. Users can activate these 
routines with a simple scripting language so that they don't write their 
own kernel modules, this limits their ability to compromise the 
integrity of the system. We expect users to use this method 
predominantly in the safe mode.

>  
>
>>>-int register_kprobe(struct kprobe *p)
>>>+static int __kprobes in_kprobes_functions(unsigned long addr)
>>>+{
>>>+	/* Linker adds these: start and end of __kprobes functions */
>>>+	extern char __kprobes_text_start[], __kprobes_text_end[];
>>>      
>>>
>>There's an old unix convention that section markers (start, end, edata,
>>etc) are declared `int'.  For some reason we don't do that in the kernel. 
>>Oh well.
>>    
>>
>
>The Linux convention is to put it into asm-generic/sections.h at least.
>
>-Andi
>
>  
>



      parent reply	other threads:[~2005-07-07 21:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-07 10:10 [1/6 PATCH] Kprobes : Prevent possible race conditions generic changes Prasanna S Panchamukhi
2005-07-07 10:11 ` [2/6 PATCH] Kprobes : Prevent possible race conditions i386 changes Prasanna S Panchamukhi
2005-07-07 10:14   ` [3/6 PATCH] Kprobes : Prevent possible race conditions x86_64 changes Prasanna S Panchamukhi
2005-07-07 10:16     ` [4/6 PATCH] Kprobes : Prevent possible race conditions ppc64 changes Prasanna S Panchamukhi
2005-07-07 10:18       ` [5/6 PATCH] Kprobes : Prevent possible race conditions ia64 changes Prasanna S Panchamukhi
2005-07-07 10:20         ` [6/6 PATCH] Kprobes : Prevent possible race conditions sparc64 changes Prasanna S Panchamukhi
2005-07-08  2:06         ` [5/6 PATCH] Kprobes : Prevent possible race conditions ia64 changes Keshavamurthy Anil S
2005-07-08 11:10           ` Prasanna S Panchamukhi
2005-07-08 19:01             ` Keshavamurthy Anil S
2005-07-08 19:16               ` Prarit Bhargava
2005-07-08 14:13       ` [4/6 PATCH] Kprobes : Prevent possible race conditions ppc64 changes Ananth N Mavinakayanahalli
2005-07-08 11:07     ` [3/6 PATCH] Kprobes : Prevent possible race conditions x86_64 changes Prasanna S Panchamukhi
2005-07-07 13:19   ` [2/6 PATCH] Kprobes : Prevent possible race conditions i386 changes Andi Kleen
2005-07-08 11:05     ` Prasanna S Panchamukhi
2005-07-07 10:25 ` [1/6 PATCH] Kprobes : Prevent possible race conditions generic changes Andrew Morton
2005-07-07 10:34   ` Andi Kleen
2005-07-07 13:01     ` Prasanna S Panchamukhi
2005-07-08 11:02       ` Prasanna S Panchamukhi
2005-07-07 21:20     ` Vara Prasad [this message]

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=42CD9CA8.5080807@us.ibm.com \
    --to=prasadav@us.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prasanna@in.ibm.com \
    --cc=systemtap@sources.redhat.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox