lkml.org 
[lkml]   [2009]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc 2/2] x86, bts: use physically non-contiguous trace buffer
On Fri, 24 Apr 2009 10:00:55 +0200 Markus Metzger <markus.t.metzger@intel.com> 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.

The changelog provides no reason for this change. It should do so.

> 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.

I suppose you could allocate the pages by hand and then vmap() them.
Allocating 2* the number you need and then freeing every second one
should make them physically holey.

> --- 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;
>

The patch looks like a regression to me. vmalloc memory is slower to
allocate, slower to free, slower to access and can exhaust or fragment
the vmalloc arena. Confused.


\
 
 \ /
  Last update: 2009-04-24 10:25    [W:0.431 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site