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]
Message-ID: <20120205191708.GA5337@neilslaptop.think-freely.org>
Date:	Sun, 5 Feb 2012 14:17:08 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	"Frank Ch. Eigler" <fche@...stic.org>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	Satoru Moriya <satoru.moriya@....com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"tgraf@...radead.org" <tgraf@...radead.org>,
	"stephen.hemminger@...tta.com" <stephen.hemminger@...tta.com>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	Seiji Aguchi <seiji.aguchi@....com>, fche@...rceware.org
Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission

On Sun, Feb 05, 2012 at 07:53:25AM -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Sat, Feb 04, 2012 at 03:09:37PM -0500, Neil Horman wrote:
> > [...]
> 
> > Systemtap is fine for development.  Lots of application/product
> > vendors really don't like it.  On top of the difficult to use
> > aspect
> 
> (Just curious, what difficulty-to-use aspect have you more recently
> come across?)
> 
Generally the fact that probe points may shift underneath a script between
kernels.  While its often ok, theres no guaranteed fixed set of probe points.
While it often works, theres always the possibility that functional changes,
even if they don't reults in behavioral changes to userspace, require re-working
of stap scripts.  Its not the sort of thing that works will for people trying to
build applications.

> > it requires that debugging stabs info be kept with the kernel, which
> > is a real pain, especially if you're running on a stable kernel.
> > [...]
> 
> You probably mean when running on an unstable kernel, no?  Installing
> debuginfo for a stable kernel is a one-time event.  It also enables
No its a one time-per kernel event.  Unless you plan on never updating your
kernel, you still have to install the corresponding debuginfo with each kernel
that you update to.

> "perf probe" and crash(8) and other tools.  Plus, with systemtap,
> there are two separate network-remoting mechanisms (--use-server
> compilation and --remote execution) that make local debuginfo
> unnecessary.
> 
Yes, but as I noted above, these are development and problem determination
tools, things that either a developer will use or a sysadmin will install on
demand when trying to diagnose a problem in the system.  People balk when buying
an application and find out that to run it requires the addition of a few Gigs
of debuginfo information, even if it enables other tools too.

> Anyway, a reasonable way to go may be to prototype in stap whatever
> hard-coded kernel module y'all envision finally doing this work.
> 
Absolutely, and from what I understand this is what Satoru has already done.
Their flight recorder does tcp retransmit stat counting using systemtap
currently, and he's now looking to codify the feature as they currently have it
using a slightly more stable API.  The tracepoint has been balked at, so I was
suggesting using netfilter as an alternate solution

Neil

> - FChE
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ