netdev - Re: [RFC] addition of a dropped packet notification service

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: <20090224.234840.93952093.davem@davemloft.net>
Date:	Tue, 24 Feb 2009 23:48:40 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	nhorman@...driver.com, shemminger@...tta.com,
	netdev@...r.kernel.org, kuznet@....inr.ac.ru, pekkas@...core.fi,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org
Subject: Re: [RFC] addition of a dropped packet notification service

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Mon, 9 Feb 2009 21:21:34 +1100

> On Sat, Feb 07, 2009 at 12:49:32PM -0500, Neil Horman wrote:
> >
> > Well, as I mentioned, its totally incomplete.  I only posted it, so that you
> > could see an exemplar of how I wanted to use tracepoints to dynamically
> > intercept various in kernel events so that I could gather drop notifications. Of
> > course several other tracepoints will be needed to capture other classes of drop
> > (IPv6 stats, arp queue overflows, qdisc drops, etc).
> 
> FWIW it sounds pretty reasonable to me.  Although I'm still unsure
> on what impact all these trace points will have on the maintainence
> of our source code.

It occurs to me that this kind of event tracking is more about
a negated test rather than a straight one.

It makes no sense to annotate all of the abnormal drop cases,
there are tons of those.

Rather it's easier to consolidate the normal cases.

Here's an idea that doesn't use tracepoints (I really don't like
them, to be honest):

1) Isolate the normal packet freeing contexts, have them call
   kfree_skb_clean() or something like that.

2) What remains are the abnormal drop cases.  They still call
   plain kfree_skb() which records __builtin_return_address(0)
   and builds a hash table of counts call sites.

Then you just dump the table via some user visible interface.
--
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