netdev - Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree

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: <20080807.031058.193703340.davem@davemloft.net>
Date:	Thu, 07 Aug 2008 03:10:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jarkao2@...il.com
Cc:	jussi.kivilinna@...et.fi, kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree_skb

From: Jarek Poplawski <jarkao2@...il.com>
Date: Thu, 7 Aug 2008 10:09:10 +0000

> On Wed, Aug 06, 2008 at 10:09:11PM -0700, David Miller wrote:
> > From: David Miller <davem@...emloft.net>
> > Date: Wed, 06 Aug 2008 20:26:36 -0700 (PDT)
> > 
> > > 
> > > 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.
--
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