netdev - RE: [PATCH] NET: Fix sch_prio to detect the root qdisc loading

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] [day] [month] [year] [list]

Message-ID: <D5C1322C3E673F459512FB59E0DDC329034462BB@orsmsx414.amr.corp.intel.com>
Date:	Sun, 22 Jul 2007 11:56:24 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	<davem@...emloft.net>, <netdev@...r.kernel.org>, <jeff@...zik.org>
Subject: RE: [PATCH] NET: Fix sch_prio to detect the root qdisc loading

> As explained in my last mail, sch->parent is an integer. And 
> it is set when grafting the qdisc, not on initilization, so 
> it is always 0 here when coming from prio_init.
> 
> This untested patch should make sure its always set correctly.

Yes, I'm using NULL and 0 interchangeably here, since in the sch_api
code, qdisc_graft(), sch->parent is referenced using NULL and not 0.  I
know it's a u32, and the value is getting set to the proper handle when
the qdisc is not the root qdisc.  When it's the root qdisc, it's left to
be 0.

This patch was tested as well, but looking at the history now, I didn't
set bands correctly, so that's why the multiqueue case failed.  My
mistake, and I'll keep working on this.

Sorry for the extra noise,
-PJ
-
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