linux-kernel - Re: [PATCH 00/23] tracehook

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:	Thu, 17 Jul 2008 01:51:05 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Roland McGrath <roland@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/23] tracehook

On Thu, 17 Jul 2008 00:25:41 -0700 (PDT) Roland McGrath <roland@...hat.com> wrote:

> This patch series introduces the "tracehook" interface layer of inlines
> in <linux/tracehook.h>.

Looks sane to me from a quick scan.

A ~200 byte increase in i386 allnoconfig .text is liveable with.  But
nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet.  What effect will that
have?

I don't like the name!  We have ftrace and we have static tracepoints
and we have dynamic tracepoints and we have linux trace toolkit and
whatever is in kernel/trace/trace.c etc, etc.  Now this work comes
along with _userspace_ tracing capabilities and it goes and calls it,
of all things, "trace"!

Things would be much less confusing were we to do s/trace/xyzzy/g on
the whole patchset.

Apart from that, I think the other big issue with this patchset is that
it doesn't do anything yet.  It's effectively a blank cheque.  There's
not a lot of point in merging all this work unless we also merge
something which uses it (is this correct?).  And afacit the thing which
will use it is utrace and utrace hasn't been sighted for a year or more
and it has met objections.

If we merge this and then utrace crashes on a rocky shore then there
was no (or little) point in having merged this.

Or am I wrong about that?  Does it have sufficient standalone value to
justify a standalone merge (yet alone to justify such a late merge)?
--
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/