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
| ||
|
Message-ID: <20120206155305.GB3620@hmsreliant.think-freely.org> Date: Mon, 6 Feb 2012 10:53:05 -0500 From: Neil Horman <nhorman@...driver.com> To: "Frank Ch. Eigler" <fche@...hat.com> Cc: Hagen Paul Pfeifer <hagen@...u.net>, "Frank Ch. Eigler" <fche@...stic.org>, 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, mathieu.desnoyers@...ymtl.ca, rostedt@...dmis.org Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission On Mon, Feb 06, 2012 at 10:20:19AM -0500, Frank Ch. Eigler wrote: > Hi, Neil - > > On Sun, Feb 05, 2012 at 08:32:47PM -0500, Neil Horman wrote: > > > [...] > > > Hey Neil, I though about this more deeply. In my first iteration I > > > had the same answer. But IMHO if you think about this more deeply, > > > I think this is not a scalable approach (implementing in userspace > > > as systemtap scripts compared to implement them in kernelspace > > > (tracepoints). Why? Because at a deep TCP level the API (and thus > > > the context) is not static and the meaning of return values (or > > > arguments) change over time. No matter _where_ it is implemented > > > or coded. > > > Yes, this is why I'm suggesting alternatives to the tracepoint. > > I believe Hagen's point was that alternatives to tracepoints would > have substantially the same difficulty. At some point in the stack, > you have to standardize/abstract. What you hook up *at that point* is > not too important: tracepoints, or function calls, or expanded perf > machinery all seem to have the same burden. > Yes, that was his point. Mine was that, given Satoru's needs, a netfilter hook provides 90% of what they need (as its been described here). If you're unfamiliar with them, netfilter hooks are those standard points in the network input/output/forwarding paths at which we can watch and maniupulate network traffic. They're what iptables/ip6tables/ebtables/etc use to do everything they do. I'm suggesting that they use those existing hooks to monitor outgoing traffic for whatever information they want (in this case retransmitted unacked tcp sequence numbers). Or whatever else their interested in. As for the other 10% (recording failed retransmits, which don't generate traffic), we have existing tracepoints that can be used. > > > [...] If something is needed in the short term for Satoru, I still > > think a privately maintained module that registers a netfilter hook > > to watch outgoing packets for retransmits offers a good solution. > > Does this mean that this netfilter hook mechanism is sufficient to > adapt to the current/future diversity of behaviors? Why not make > *that* into a tracepoint then, so perf/stap scripts could get at it in > userspace? > I suppose you could. In fact there is a queue target that lets you shuttle frames from netfilter hook points up to userspace already, so you could do that. I'm suggesting a kernel module because then you wouldn't have the performance overhead of moving all those frames to user space. 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