From: Jarek Poplawski <redacted>
Date: Thu, 7 Aug 2008 10:09:10 +0000

On Wed, Aug 06, 2008 at 10:09:11PM -0700, David Miller wrote:

quoted

From: David Miller <davem@davemloft.net>
Date: Wed, 06 Aug 2008 20:26:36 -0700 (PDT)

quoted

I still haven't seen anyone suggest creating a __NET_XMIT_KFREE_SKB to
fix this most rediculious problem.

I'm still waiting...

Here is what it might look like.  I haven't tried to boot this,
but the only non-trivial case was SFQ's congestion drop code.

After some checking it looks mostly OK to me, but one thing: in
sch_gred gred_drop() calls qdisc_drop(), so now it needs kfree_skb().
BTW, maybe it would be nicer to add __qdisc_drop() for these new
things?

qdisc_drop() sets the new __NET_XMIT_KFREE bit, but sch_gred wants to
return NET_XMIT_CN, so I OR'd in the __NET_XMIT_KFREE bit there.

There is also some doubt about differences between ->enqueue() and
->requeue() wrt. kfree_skb() and returning codes: maybe it would be
better (for uniformity) to add similar changes to requeues (and
dev_requeue_skb()) as well?

I did not annotate ->requeue() nor remove kfree_skb() calls there
and this was intentional.

The lifetime issue only exists in the ->enqueue() path.

In the long term we could add a wrapper around root level ->requeue()
and do the bit handling just like ->enqueue(), sure.

I don't know if it's worth to mention, but now, if somebody really
uses this sch_blackhole under some upper qdiscs the stats will change.

That might even be useful.

As it stands it was borderline buggy.