netdev - Re: [PATCH] sch_htb: ix the deficit overflows

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: <20091130111020.GA7114@ff.dom.local>
Date:	Mon, 30 Nov 2009 11:10:20 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Changli Gao <xiaosuo@...il.com>
Cc:	Jamal Hadi Salim <hadi@...erus.ca>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Martin Devera <martin.devera@....cz>
Subject: Re: [PATCH] sch_htb: ix the deficit overflows

On Mon, Nov 30, 2009 at 12:26:33PM +0800, Changli Gao wrote:
> On Sat, Nov 28, 2009 at 8:04 AM, Jarek Poplawski <jarkao2@...il.com> wrote:
> > Changli Gao wrote, On 11/27/2009 09:14 AM:
> >
> >
> > This case of the quantum smaller than the packet size should be treated
> > as a broken config, so I don't think it's worth to do such a deep change
> > with additional delays and cpu cycles for all to fix it. A warning or
> > lower limit should be enough (if necessary at all).
> >
> 
> I don't think this change is deep. HTB has it own lower limit for
> quantum 1000, but the MTU is various, and maybe larger than that.

Users can control this with "r2q" and "quantum", and there is a hint
on quantum size in the user's guide.

> And
> if we use IMQ to shape traffic, the skb will be defragmented by
> conntrack, and its size will be larger than MTU.

IMQ is a very nice thing, but it's considered broken as well, so it
can't be the reason for changing HTB.

> 
> The previous patch indeed introduces some additional CPU cycles.
> Review  the new patch bellow please:

And this patch is very similar, except ->peek()/dequeue(). Additional
lookups are done instead of dequeuing the first found class, which
might be quite long in some cases.

> 
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index 2e38d1a..d55382b 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -815,6 +815,17 @@ next:
>                         goto next;
>                 }
> 
> +               if (unlikely(cl->un.leaf.deficit[level] < 0)) {
> +                       cl->un.leaf.deficit[level] += cl->quantum;
> +                       htb_next_rb_node((level ? cl->parent->un.inner.ptr :
> +                                         q->ptr[0]) + prio);
> +                       cl = htb_lookup_leaf(q->row[level] + prio, prio,
> +                                            q->ptr[level] + prio,
> +                                            q->last_ptr_id[level] + prio);
> +                       start = cl;
> +                       goto next;
> +               }
> +
>                 skb = cl->un.leaf.q->dequeue(cl->un.leaf.q);
>                 if (likely(skb != NULL))
>                         break;
> 
> If you think it is acceptable, I'll resubmit it for inclusion.

It's not acceptable to me mainly because the real change done by this
patch is different than you describe: preventing an overflow might be
simple. You change the way DRR is implemented here, and even if it's
right, it should be written explicitly and proved with tests results.

Anyway, I think you should rather care for the author's acceptance,
because the way it's done doesn't look like accidental and has been
heavily tested btw. (I added Martin to CC.)

Regards,
Jarek P.

PS: Btw, this newer version of the patch is broken with spaces.
--
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