netdev
[Top] [All Lists]

Re: gred_dump (2.4.17): bad semantic and memory leak

To: <kuznet@xxxxxxxxxxxxx>
Subject: Re: gred_dump (2.4.17): bad semantic and memory leak
From: jamal <hadi@xxxxxxxxxx>
Date: Sat, 19 Jan 2002 15:10:29 -0500 (EST)
Cc: <netdev@xxxxxxxxxxx>
In-reply-to: <200201191953.WAA32293@ms2.inr.ac.ru>
Sender: owner-netdev@xxxxxxxxxxx

On Sat, 19 Jan 2002 kuznet@xxxxxxxxxxxxx wrote:

> Hello!
>
> > GRED insists that table->initd is non-zero to be completely configured.
>
> No matter what gred insists on, it must not return error to dump.
>
> And you say wrong thing about atomicity. gred may not work while being
> configured, but it always has some _state_ and is able to show it to dump.
>
> rtattr_failure happens only when there is no room in skb.
>
> Please, return success and an information about current state of gred.
>

It does have some state. Note it will continue to work even if half
configured just using default parameters ..
How about totaly removing that check? It would report accumulated state
just fine ... i.e


--- sch_gred.c  2002/01/19 20:05:59     1.2
+++ sch_gred.c  2002/01/19 20:09:05
@@ -518,10 +518,6 @@

        memset(opt, 0, (sizeof(struct tc_gred_qopt))*table->DPs);

-       if (!table->initd) {
-               DPRINTK("NO GRED Queues setup!\n");
-               goto rtattr_failure;
-       }

        for (i=0;i<MAX_DPs;i++) {
                dst= &opt[i];




cheers,
jamal


<Prev in Thread] Current Thread [Next in Thread>