lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 4 Apr 2008 19:19:43 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH] relay: add buffer-only functionality, allowing for
 early kernel tracing

On Fri, 4 Apr 2008 12:06:23 -0400
Mathieu Desnoyers <compudj@...stal.dyndns.org> wrote:

> I like this :) But could we trace event sooner if we did not depend on
> vmalloc to allocate the buffers ?
> 
> I am thinking of receiving a kernel parameter that would reserve a
> buffer in the linear kernel mapping (kmalloc ?), or to compile-in a
> static buffer, which could be used by relay instead of the vmalloc'd
> buffer. That would permit to trace the memory allocator and some other
> very early stuff. Basically, relay would have it's "memory pool" to
> manage and would do its allocations from this fixed buffer. No free
> would be required.
> 
> Mathieu

Sure. I'm doing this as part of my GSoC application (well, I haven't
been accepted yet). I had also proposed this to Pekka Enberg, my
mentor, but he was reluctant to hack the relay code more invasively. Now
that you agree with this, I'll work on it.

kmalloc() doesn't work before kmem_cache_init() and relay code uses
kmalloc(), not vmalloc(), IIRC.

I would go another way. Have the relay client call __get_free_pages()
or similar function, allocate the buffer and pass it on to a variant of
relay_open(), let's name it relay_early_open(). __get_free_pages() can
be used before kmem_cache_init() as far as I know. No free is required,
since early tracing code implies it's built into the kernel and not as
a module. What do you say?

Will you merge this or wait until I finish the very early tracing stuff?

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

Powered by blists - more mailing lists