upgrading kernel breaks tc ?

upgrading kernel breaks tc ?

[Akshat Kakkar]

I am running sl6.3 (i.e. kernel 2.6.32-279).
I upgraded the kernel (and only kernel) using elrepo to kernel 4.1.4.

Now when I boot with this new kernel, and try to delete specific tc
filter, it is not happening. It is instead deleting all the filters.
Following is the commanf I am trying,

tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3 u32

It is behaving exactily as the command without handle, i.e. like

tc filter del dev eth1 protocol ip parent 1: prio 5

In old kernel, it was deleting only a single filter.

Does kernel upgrade breaks tc and that too so silently?

Re: upgrading kernel breaks tc ?

[Akshat Kakkar]

Please help ...

I apologize for being so impatient ...

On Thu, Aug 20, 2015 at 1:48 PM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> I am running sl6.3 (i.e. kernel 2.6.32-279).
> I upgraded the kernel (and only kernel) using elrepo to kernel 4.1.4.
>
> Now when I boot with this new kernel, and try to delete specific tc
> filter, it is not happening. It is instead deleting all the filters.
> Following is the commanf I am trying,
>
> tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3 u32
>
> It is behaving exactily as the command without handle, i.e. like
>
> tc filter del dev eth1 protocol ip parent 1: prio 5
>
> In old kernel, it was deleting only a single filter.
>
> Does kernel upgrade breaks tc and that too so silently?

Re: upgrading kernel breaks tc ?

[Andy Furniss]

Akshat Kakkar wrote:
> I am running sl6.3 (i.e. kernel 2.6.32-279). I upgraded the kernel
> (and only kernel) using elrepo to kernel 4.1.4.

You won't get new features without updating TC - but your test case on
my setup still deletes all the filters with matching tc.

> Now when I boot with this new kernel, and try to delete specific tc
> filter, it is not happening. It is instead deleting all the filters.
>  Following is the commanf I am trying,
>
> tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3
> u32

But earlier you found that handle alone wasn't unique so you should have
used the whole command line that you added.

Saying that it still deletes all, so that wasn't it.

> It is behaving exactily as the command without handle, i.e. like
>
> tc filter del dev eth1 protocol ip parent 1: prio 5

It maybe a bug or it maybe that old kernel was unsafe letting you delete
something that is going to get hashed to.

FWIW using replace/change + full command (with eg. flowid changed) works
for me, but I didn't find a way to change anything else - which doesn't
mean there isn't a way, just that I am not familiar with
hashing/advanced tc.

Historically I always used to just remove the root qdisc and start again
to change something, as it was safer/less error prone. If you have 000s
of rules then use batch mode which will be way, way, faster than
inputting them with a script.

Re: upgrading kernel breaks tc ?

[Akshat Kakkar]

I thinks its a Bug!!!

When I am deleting in hashtable other than 800: then it is deleting
all filters but in 800: it is deleting only the specified filter

For example, following set of commands  create a hashtable 15: and add
2 filters to it.

tc filter add dev eth0 parent 1:0 prio 5 handle 15: protocol ip u32 divisor 256
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:2 u32
ht 15:2: match ip src 10.0.0.2 flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32
ht 15:2: match ip src 10.0.0.3 flowid 1:10

Now following command DELETES ALL THE FILTERS !
tc filter del dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32

O/p of tc filter show eth0 is this case is blank. As all filters are deleted.


However, similar commands when executed for hashtable 800: is deleting
only the specified filter
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32
ht 800:0: match ip src 10.0.0.2 flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:3 u32
ht 800:0: match ip src 10.0.0.3 flowid 1:10

tc filter del dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32

Above mentioned command only deletes single filter.
O/p of tc filter show eth0 is 2nd case is

filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::3 order 3 key ht 800
bkt 0 flowid 1:10
  match 0a000003/ffffffff at 12







On Thu, Aug 20, 2015 at 4:04 PM, Andy Furniss <adf.lists@gmail.com> wrote:
> Akshat Kakkar wrote:
>>
>> I am running sl6.3 (i.e. kernel 2.6.32-279). I upgraded the kernel
>> (and only kernel) using elrepo to kernel 4.1.4.
>
>
> You won't get new features without updating TC - but your test case on
> my setup still deletes all the filters with matching tc.
>
>> Now when I boot with this new kernel, and try to delete specific tc
>> filter, it is not happening. It is instead deleting all the filters.
>>  Following is the commanf I am trying,
>>
>> tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3
>> u32
>
>
> But earlier you found that handle alone wasn't unique so you should have
> used the whole command line that you added.
>
> Saying that it still deletes all, so that wasn't it.
>
>> It is behaving exactily as the command without handle, i.e. like
>>
>> tc filter del dev eth1 protocol ip parent 1: prio 5
>
>
> It maybe a bug or it maybe that old kernel was unsafe letting you delete
> something that is going to get hashed to.
>
> FWIW using replace/change + full command (with eg. flowid changed) works
> for me, but I didn't find a way to change anything else - which doesn't
> mean there isn't a way, just that I am not familiar with
> hashing/advanced tc.
>
> Historically I always used to just remove the root qdisc and start again
> to change something, as it was safer/less error prone. If you have 000s
> of rules then use batch mode which will be way, way, faster than
> inputting them with a script.

Re: upgrading kernel breaks tc ?

[Akshat Kakkar]

I test it on centos 7 fresh image, but still the same behaviour.

So its either a feature set or a bug? But reason behind it to be a
feature is not clear. Can anyone throw light at it?


Besides, how (in my actual case of kernel upgrade) come simple kernel
upgrade i.e. installation of kernel.rpm causes this behaviour to be
infused in tc? Does upgrading kernel automatically upgrades tc (or
iproute)? I dont think so...
But then how it all happened?

Please help ...

Its getting pretty tricky out here ...

On Thu, Aug 20, 2015 at 5:21 PM, Akshat Kakkar <akshat.1984@gmail.com> wrote:
> I thinks its a Bug!!!
>
> When I am deleting in hashtable other than 800: then it is deleting
> all filters but in 800: it is deleting only the specified filter
>
> For example, following set of commands  create a hashtable 15: and add
> 2 filters to it.
>
> tc filter add dev eth0 parent 1:0 prio 5 handle 15: protocol ip u32 divisor 256
> tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:2 u32
> ht 15:2: match ip src 10.0.0.2 flowid 1:10
> tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32
> ht 15:2: match ip src 10.0.0.3 flowid 1:10
>
> Now following command DELETES ALL THE FILTERS !
> tc filter del dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32
>
> O/p of tc filter show eth0 is this case is blank. As all filters are deleted.
>
>
> However, similar commands when executed for hashtable 800: is deleting
> only the specified filter
> tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32
> ht 800:0: match ip src 10.0.0.2 flowid 1:10
> tc filter add dev eth0 protocol ip parent 1: prio 5 handle 800:0:3 u32
> ht 800:0: match ip src 10.0.0.3 flowid 1:10
>
> tc filter del dev eth0 protocol ip parent 1: prio 5 handle 800:0:2 u32
>
> Above mentioned command only deletes single filter.
> O/p of tc filter show eth0 is 2nd case is
>
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::3 order 3 key ht 800
> bkt 0 flowid 1:10
>   match 0a000003/ffffffff at 12
>
>
>
>
>
>
>
> On Thu, Aug 20, 2015 at 4:04 PM, Andy Furniss <adf.lists@gmail.com> wrote:
>> Akshat Kakkar wrote:
>>>
>>> I am running sl6.3 (i.e. kernel 2.6.32-279). I upgraded the kernel
>>> (and only kernel) using elrepo to kernel 4.1.4.
>>
>>
>> You won't get new features without updating TC - but your test case on
>> my setup still deletes all the filters with matching tc.
>>
>>> Now when I boot with this new kernel, and try to delete specific tc
>>> filter, it is not happening. It is instead deleting all the filters.
>>>  Following is the commanf I am trying,
>>>
>>> tc filter del dev eth1 protocol ip parent 1: prio 5 handle 800:0:3
>>> u32
>>
>>
>> But earlier you found that handle alone wasn't unique so you should have
>> used the whole command line that you added.
>>
>> Saying that it still deletes all, so that wasn't it.
>>
>>> It is behaving exactily as the command without handle, i.e. like
>>>
>>> tc filter del dev eth1 protocol ip parent 1: prio 5
>>
>>
>> It maybe a bug or it maybe that old kernel was unsafe letting you delete
>> something that is going to get hashed to.
>>
>> FWIW using replace/change + full command (with eg. flowid changed) works
>> for me, but I didn't find a way to change anything else - which doesn't
>> mean there isn't a way, just that I am not familiar with
>> hashing/advanced tc.
>>
>> Historically I always used to just remove the root qdisc and start again
>> to change something, as it was safer/less error prone. If you have 000s
>> of rules then use batch mode which will be way, way, faster than
>> inputting them with a script.

Re: upgrading kernel breaks tc ?

[Martin A. Brown]

Greetings Akshat Kakkar,

> I thinks its a Bug!!!

If it's a bug and reproducible (given your test case below, it seems 
plausible), perhaps you should take this to the netdev@ mailing 
list.  I do not know how they accept bugs, whether on that list or 
via a bug-tracking interface someplace, but you might re-post this 
on that list and get some advice on what you should do.

The developers on the netdev list will be much more likely to be 
able to help you with this particular problem than those of us on 
the lartc list.

Good luck,

-Martin

N.B. I did not try to reproduce your test case...

   [snip]

-- 
Martin A. Brown
http://linux-ip.net/

Re: upgrading kernel breaks tc ?

[Akshat Kakkar]

No reply from netdev. Where else I can get help ?

On Thu, Aug 20, 2015 at 9:40 PM, Martin A. Brown <martin@linux-ip.net> wrote:
>
> Greetings Akshat Kakkar,
>
>> I thinks its a Bug!!!
>
>
> If it's a bug and reproducible (given your test case below, it seems
> plausible), perhaps you should take this to the netdev@ mailing list.  I do
> not know how they accept bugs, whether on that list or via a bug-tracking
> interface someplace, but you might re-post this on that list and get some
> advice on what you should do.
>
> The developers on the netdev list will be much more likely to be able to
> help you with this particular problem than those of us on the lartc list.
>
> Good luck,
>
> -Martin
>
> N.B. I did not try to reproduce your test case...
>
>   [snip]
>
> --
> Martin A. Brown
> http://linux-ip.net/