netdev - Re: [PATCH] net/sched/sch_hfsc.c: initialize parent's cl_cfmin properly in init

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: <20100918140816.GA974@mott.hasevolq.tld>
Date:	Sat, 18 Sep 2010 16:08:16 +0200
From:	Michal Soltys <soltys@....info>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, denys@...p.net.lb,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net/sched/sch_hfsc.c: initialize parent's cl_cfmin
 properly in init_vf()

On Wed, Sep 15, 2010 at 11:42:57PM +0200, Michal Soltys wrote:
> On 10-09-15 19:54, Patrick McHardy wrote:
> >Am 01.09.2010 23:30, schrieb David Miller:
> >> From: Michal Soltys<soltys@....info>
> >> Date: Mon, 30 Aug 2010 23:34:10 +0200
> >>
> >>> This patch fixes init_vf() function, so on each new backlog period parent's
> >>> cl_cfmin is properly updated (including further propgation towards the root),
> >>> even if the activated leaf has no upperlimit curve defined.
> >>>
> >>> Signed-off-by: Michal Soltys<soltys@....info>
> >>
> >> Applied, thanks.
> >
> >For the record, the patch seems fine to me. The root cause seems to be
> >an optimization I introduced (pre-git, even history.git unfortunately)
> >in vttree_get_minvt() that wasn't present in the original version:
> >
> >static struct hfsc_class *
> >vttree_get_minvt(struct hfsc_class *cl, u64 cur_time)
> >{
> >         /* if root-class's cfmin is bigger than cur_time nothing to do */
> >         if (cl->cl_cfmin>  cur_time)
> >                 return NULL;
> >
> >I'd prefer to remove this check since it's obviously not correct and
> >might cause other problems. Michal, could you please test whether this
> >patch fixes the problem as well? Thanks!
> 
> Sure, will do. Although with a tad bit more complex scenario than
> from my cover email, I think there will still be problems.

Ok, did the tests. The results confirmed the earlier theory - namely, if I
removed my fix and your optimization, the only scenario it helped with was if
the leafs were directly attached to the root qdisc, eg.:

    root
    /  \
   A    B(u)

Here, making decision at root would go through childrens' 'vt's and 'f's times
and properly dequeue A without any delays.

Anything deeper though, like:

     |                / \
     A               A   B(u)
    / \             / \
   B   C(u)        C  D(u)

still cause problems - while the decision would go through 'vt's and 'f's - the
'f's are calculated as max(myf, cfmin), and cfmin won't be updated updwards
from the leafs that have no upperlimit.

Regarding your optimization - its results should be consistent with the first
vttree_firstfit() call (if cf_min is properly updated). I don't see how it
could cause any misbehaviour.

Speaking about hfsc, I have few other potential changes with reference to how
vt is handled and updated (especially cvtmin), but that's for different mail.

Additional 'if' condition (mentioned in previous mail) in my fix seemed to work
fine as well, namely:

diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 4749609..e9768b2 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -761,8 +761,9 @@ init_vf(struct hfsc_class *cl, unsigned int len)
 		if (f != cl->cl_f) {
 			cl->cl_f = f;
 			cftree_update(cl);
-		}
-		update_cfmin(cl->cl_parent);
+			update_cfmin(cl->cl_parent);
+		} else if (go_active)
+			update_cfmin(cl->cl_parent);
 	}
 }

--
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