linux-kernel - Re: [PATCH] relay: add buffer-only functionality, allowing for early kernel tracing

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 20:06:10 +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>,
	Tom Zanussi <zanussi@...ibm.com>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [PATCH] relay: add buffer-only functionality, allowing for
 early kernel tracing

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

> Then I guess we would depend on page_alloc_init(). It's not that bad,
> but I guess the question is : do we prefer to let users specify the
> buffer size to reserve for tracing on the kernel command line (that
> would require __get_free_pages()) or do we compile-in a static buffer
> size, which can be specified in the kernel configuration. I think
> providing both could be an option : flexibility _and_ *very* early
> tracing.

I wasn't referring to the kernel's users specifying the buffer on the
command line. For example, LTTng code (I'm not familiar with it) could
allocate a buffer, by itself or using a helper function, and pass it to
relay_early_open(). Of course, it could read the command line and call
that helper function, passing the size required by the user as an
argument.

Basically, I'm saying that having relay code manage a large buffer,
allocating memory from it for each of its callers, could be very
complex. It would be easier and less complex to let each tracing
subsystem allocate memory on its own, either through a static buffer or
with __get_free_pages().

> So making this relay interface flexible enough to receive a buffer
> either reserved by __get_free_pages() or a static buffer seems like a
> good compromise. It would also have to receive the buffer size from
> the caller.

Yes, it shouldn't matter to the relay interface whether the buffer was
statically or dynamically allocated. All it needs to know is where it
starts and how long it is.

BTW, I'll resubmit a modified patch soon, as suggested by Randy Dunlap.

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/