netdev - Re: net_sched: dsmark: use qdisc_dequeue

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: <1456953590.3297.58.camel@kyeongy-dl>
Date:	Wed, 2 Mar 2016 21:19:51 +0000
From:	Kyeong Yoo <Kyeong.Yoo@...iedtelesis.co.nz>
To:	"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>
CC:	"jhs@...atatu.com" <jhs@...atatu.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: net_sched: dsmark: use qdisc_dequeue_peeked()

Author: Kyeong Yoo <kyeong.yoo@...iedtelesis.co.nz>

net_sched: dsmark: use qdisc_dequeue_peeked()

This fix is for dsmark similar to commit 3557619f0f6f7496ed453d4825e249
("net_sched: prio: use qdisc_dequeue_peeked")
and makes use of qdisc_dequeue_peeked() instead of direct dequeue() call.

First time, wrr peeks dsmark, which will then peek into sfq.
sfq dequeues an skb and it's stored in sch->gso_skb.
Next time, wrr tries to dequeue from dsmark, which will call sfq dequeue
directly. This results skipping the previously peeked skb.

So changed dsmark dequeue to call qdisc_dequeue_peeked() instead to use
peeked skb if exists.

Signed-off-by: Kyeong Yoo <kyeong.yoo@...iedtelesis.co.nz>

diff --git a/net/sched/sch_dsmark.c b/net/sched/sch_dsmark.c
index f357f34..b204472 100644
--- a/net/sched/sch_dsmark.c
+++ b/net/sched/sch_dsmark.c
@@ -281,7 +281,7 @@ static struct sk_buff *dsmark_dequeue(struct Qdisc *sch)
 
 	pr_debug("%s(sch %p,[qdisc %p])\n", __func__, sch, p);
 
-	skb = p->q->ops->dequeue(p->q);
+	skb = qdisc_dequeue_peeked(p->q);
 	if (skb == NULL)
 		return NULL;

On Wed, 2016-03-02 at 10:26 -0800, Cong Wang wrote:
> On Tue, Mar 1, 2016 at 8:10 PM, Kyeong Yoo
> <Kyeong.Yoo@...iedtelesis.co.nz> wrote:
> > This fix is for dsmark similar to 3557619f0f6f7496ed453d4825e24958ab1884e0,
> > and makes use of qdisc_dequeue_peeked() instead of direct dequeue() call.
> >
> > First time, wrr peeks dsmark, which will then peek into sfq.
> > sfq dequeues an skb and it's stored in sch->gso_skb.
> > Next time, wrr tries to dequeue from dsmark, which will call sfq dequeue
> > directly. This results skipping the previously peeked skb.
> >
> > So changed dsmark dequeue to call qdisc_dequeue_peeked() instead to use
> > peeked skb if exists.
> 
> 
> This part looks reasonable to me.
> 
> >
> > Also replaced dsmark peek to use qdisc_peek_dequeued() which works correctly
> > if previously peeked skb still exists.
> 
> 
> But not this part, since sfq already calls qdisc_peek_dequeued()?