All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Markus Metzger <markus.t.metzger@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [rfc 2/2] x86, bts: use physically non-contiguous trace buffer
Date: Sat, 25 Apr 2009 08:40:53 +0200	[thread overview]
Message-ID: <49F2B075.4090300@linux.intel.com> (raw)
In-Reply-To: <20090424100055.A30408@sedona.ch.intel.com>

Markus Metzger wrote:
> Use vmalloc to allocate the branch trace buffer.
> 
> Peter Zijlstra suggested to use vmalloc rather than kmalloc to
> allocate the potentially multi-page branch trace buffer.
> 
> Is there a way to have vmalloc allocate a physically non-contiguous
> buffer for test purposes? Ideally, the memory area would have big
> holes in it with sensitive data in between so I would know immediately
> when this is overwritten.

For test purposes you could hack vmalloc.c to allocate more pages
and only put in every second/third/... into the mapping. You would
just need to add another to loop to __vmalloc_area_node() that allocates
more. That should give you non continuous mappings unless you're really unlucky.

-Andi


> 
> 
> Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> CC: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
> ---
>  arch/x86/kernel/ptrace.c |    5 	3 +	2 -	0 !
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: b/arch/x86/kernel/ptrace.c
> ===================================================================
> --- a/arch/x86/kernel/ptrace.c
> +++ b/arch/x86/kernel/ptrace.c
> @@ -22,6 +22,7 @@
>  #include <linux/seccomp.h>
>  #include <linux/signal.h>
>  #include <linux/workqueue.h>
> +#include <linux/vmalloc.h>
>  
>  #include <asm/uaccess.h>
>  #include <asm/pgtable.h>
> @@ -626,7 +627,7 @@ static int alloc_bts_buffer(struct bts_c
>  	if (err < 0)
>  		return err;
>  
> -	buffer = kzalloc(size, GFP_KERNEL);
> +	buffer = vmalloc(size);
>  	if (!buffer)
>  		goto out_refund;
>  
> @@ -646,7 +647,7 @@ static inline void free_bts_buffer(struc
>  	if (!context->buffer)
>  		return;
>  
> -	kfree(context->buffer);
> +	vfree(context->buffer);
>  	context->buffer = NULL;
>  
>  	refund_locked_memory(context->mm, context->size);


  parent reply	other threads:[~2009-04-25  6:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-24  8:00 [rfc 2/2] x86, bts: use physically non-contiguous trace buffer Markus Metzger
2009-04-24  8:13 ` Andrew Morton
2009-04-24  8:31   ` Ingo Molnar
2009-04-24  8:39     ` Metzger, Markus T
2009-04-26 16:08       ` Ingo Molnar
2009-04-27 10:53     ` Peter Zijlstra
2009-04-29  9:14       ` Metzger, Markus T
2009-04-25  6:40 ` Andi Kleen [this message]
2009-04-27  6:35   ` Metzger, Markus T

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=49F2B075.4090300@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@intel.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 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.