netdev - Re: Question: how to detect if a qdisc is root or not?

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: <46A18503.8000800@trash.net>
Date:	Sat, 21 Jul 2007 06:01:07 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
CC:	netdev@...r.kernel.org
Subject: Re: Question: how to detect if a qdisc is root or not?

Waskiewicz Jr, Peter P wrote:
>>Its set after grafting the parent, which is after initialization.
>>I think what should work is to set it in qdisc_create 
>>instead, sch_api.c around line 490:
>>
>>+	sch->parent = handle;
>>
>>        if (handle == TC_H_INGRESS) {
>>                sch->flags |= TCQ_F_INGRESS;
>>                sch->stats_lock = &dev->ingress_lock; ...
>>
>>and remove the initialization in qdisc_graft. That would 
>>additionally have the benefit that ingress qdiscs also have 
>>it initialized properly.
> 
> 
> I just sent out a patch to fix this.


I didn't see it yet.

> Sorry for the delay; my
> development machine oops'd in the middle of some disk I/O, and it
> corrupted part of the inode table...the ext3 journal application seemed
> to make it worse too.  Rebuilt the machine, so I'm back on my feet.


No worries :)

> Anyways, I tried a few different things, and what it looks like is
> sch->parent will be NULL (0) for the top-level device.  This is correct,
> and trying to mess with that screws up qdisc_graft() when unloading the
> qdisc.  I also tried adding a TCQ_F_ROOT flag to sch->flags when classid
> is TC_H_ROOT, but that also screwed up unloading the qdisc.


I dont think I understand. Whats the problem with setting sch->parent
on initialization instead on grafting as I did in my example patch?
Please explain the problems arrising on unload in detail.


-
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