linux-kernel - Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

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:	13 Apr 2007 17:17:00 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	William Lee Irwin III <wli@...omorphy.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

Christoph Hellwig <hch@...radead.org> writes:

> [...]
> > merge it in the first place?
> 
> It's very nice to poke deep into the kernel for development purposes.
> For example for the spu scheduler work I'm doing currently I have
> a module using kprobes (note the systemtap crap because it's big, bloated,
> in and odd language, and does a lot of really wrong things in its runtime).

It may be worthwhile to remind people that it is easy to use systemtap
only to the extent of automating the placement of kprobes: just to
perform the function-name/source-file/line-number triplet to PC
mapping.  They can use embedded-C code to do all the same stuff they'd
do with kprobes.  They are not obligated to write any odd script code
for probing logic, nor indeed use any of this really wrong runtime.

> This module allows me to put probes into various places in the scheduler
> and writes them into a ringbuffer with timestampts allowing me to
> trace what's going on there.  This is really neat.  [...]

Indeed, and we too try to make this simple & fast: a couple of lines.

> [...] To summarize, I really love kprobes to ease my debugging work,
> but using it for any kind of production code is a total nightmare.

But at some point, some interface needs to be fixed for a final
user-space tool.  Whether that interface fixing is performed by kernel
developers being more reluctant to rewrite basic things, or by
providing a proc interface, or maintaining a kprobes module does not
matter.  Someone will feel constrained, and someone will be liberated.

One neat thing about our systemtap tool is that, no matter what layer
such interfaces become fixed within, it can probably interface to
them.  If there is no fixed interface, it can go down to debugging
info.  If there are tracing hooks present, it can attach.  It can make
appear as unified the disparate standardization policies of different
subsystems.

> > We could distribute some systemtap scripts, and even distribute some
> > basic useful ones like this sort of page info in the kernel source
> > tree.
>
> We could not really distribute systemtap scripts with the kernel.
> systemtap is a bloody complicated piece of [software] 

I don't know if that should be treated a compliment to our team, for
being able to work quickly on something that a full-grown kernel
developer finds bloody complicated.  Perhaps your information is
simply outdated.  Big & bloated?  We have several times asked for
specifics rather than smears - what about it?

> outside the kernel tree that breaks all the time we change kernel
> internals. [...]

That's begging the question.  If kernel folks are willing to maintain
some included systemtap-related code, then by definition it would not
break all the time.

- FChE
-
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/