[regression] 3.13.0-69 infinite ip rules

[Simon Déziel]

When I run the 3.13.0-69 -proposed kernel on Trusty, I'm seeing infinite amount of ip rules:

$ ip -f inet rule show | head
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local
0: from all lookup local

And it never stops:

$ time ip -f inet rule show | wc -l
^C

real 3m30.262s
user 0m46.742s
sys 3m39.516s

Deleting the "lookup local" then shows an infinite amount of "lookup main".

When I go back to 3.13.0-68, things look normal:

$ time ip -f inet rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

real 0m0.002s
user 0m0.000s
sys 0m0.002s

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1516052

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Norman Henderson (norm-audrey)]

I have the same behavior with 3.16-0-53. The system appears to be working normally in all respects including policy routing, except that the ip rule command produces an infinite loop of 0: from all lookup local. Makes it hard to manage the system... This could be a duplicate of 1514785 which applies to 3.16-0-52+53.

[Simon Déziel (sdeziel)]

Indeed, the 3.13 and 3.16 -proposed kernels have the commit I'm suspecting:

fib_rules: fix fib rule dumps across multiple skbs

The 3.19 -proposed kernel doesn't have it so I'm wondering if it's also affected.

[Simon Déziel (sdeziel)]

So 3.19.0-33 doesn't have the problem.

[Ian! D. Allen (idallen)]

The recent Ubuntu 15.04 kernel update to vmlinuz-3.19.0-37-generic installed this same bug.
I had to reboot back to vmlinuz-3.19.0-33-generic to avoid the loop.