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
| ||
|
Date: Wed, 13 May 2015 13:29:58 +0200 From: Florian Westphal <fw@...len.de> To: Jamal Hadi Salim <jhs@...atatu.com> Cc: Florian Westphal <fw@...len.de>, netdev@...r.kernel.org Subject: Re: [PATCH -next] net: sched: use counter to break reclassify loops Jamal Hadi Salim <jhs@...atatu.com> wrote: > On 05/12/15 09:00, Florian Westphal wrote: > >Jamal Hadi Salim <jhs@...atatu.com> wrote: > >>Florian, > >>In general i am in support of removing this - since the use case never > >>materialized as being useful. However, this is not the same logic that > >>was there before. To get equivalency you need to pass the limit into > >>tc_classify_compat() so i can be reset. > > > >AFAICS this re-set only happens when we return something other > >than RECLASSIFY which means the caller will not check the limit. > > > >So in fact it should be ok to remove this since the counter will always > >start from 0 on next tc_classify() invocation. > > > > Florian, consider the following scenario: > Assume X is the max allowed reclassified before bells start ringing. > If we see upto X back-to-back reclassify - we are very much likely in > a loop. We should see fire trucks arrive and bail out. > If we see X-1 "reclassify" followed by a "pipe" followed by > X-1 "reclassify" followed by "ok" then that looks like a healthy > policy. But that is a a total of 2X-2 reclassifies. You will > bail out at X reclassifies; what i am saying is you shouldnt. > And existing logic doesnt. Does that make sense? Yes, but, if we use your example above then: tc_classify called limit 0 tc_classify_compat called, ret RECLASSIFY limit 1 tc_classify_compat called, ret RECLASSIFY limit 2 tc_classify_compat called, ret PIPE (== 3) tc_classify returns 3 tc_classify called limit 0 ... So we don't toss skb since any return value other than RECLASSIFY will make tc_classify() return to its caller, and when caller invokes tc_classify again the limit variable is set to 0 again. Does that make sense to you? Thanks Jamal. -- 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
Powered by blists - more mailing lists