Re: [rfc 2/2] x86, bts: use physically non-contiguous trace buffer

From: Ingo Molnar
Date: Fri Apr 24 2009 - 04:33:15 EST



* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Fri, 24 Apr 2009 10:00:55 +0200 Markus Metzger <markus.t.metzger@xxxxxxxxx> 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.

Performance does not matter here (this is really a slowpath), but
fragmentation does matter, especially on 32-bit systems.

I'd not uglify the code via vmap() - and vmap has the same
fundamental address space limitations on 32-bit as vmalloc().

The existing kmalloc() is fine. We do larger than PAGE_SIZE
allocations elsewhere too (the kernel stack for example), and this
is a debug facility, so failing the allocation is not a big problem
even if it happens.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/