On Fri, Oct 11, 2019 at 12:54 PM Wei Wang wrote:
> Hmm... Yes... I would think a per-CPU input cache should work for the
> case above.
> Another idea is: instead of calling dst_dev_put() in rt_cache_route()
> to switch out the dev, we call, rt_add_uncached_list() to add this
> obsolete dst cache t
On Fri, Oct 11, 2019 at 1:52 PM Ido Schimmel wrote:
> I think this is fine.
>
> Jesse, can you please test Wei's patch?
I tested with a patched kernel using the same scripts and it does seem to
resolve the issue, thanks!
On Fri, Oct 11, 2019 at 10:42 AM Ido Schimmel wrote:
> Do you remember when you started seeing this behavior? I think it
> started in 4.13 with commit ffe95ecf3a2e ("Merge branch
> 'net-remove-dst-garbage-collector-logic'").
Unfortunately, our data on when the problem started is a bit fuzzy, but
On Thu, Oct 10, 2019 at 3:31 AM Ido Schimmel wrote:
> I think it's working as expected. Here is my theory:
>
> If CPU0 is executing both the route get request and forwarding packets
> through the directly connected interface, then the following can happen:
>
> - In process context, per-CPU dst en
routing
tables from multiple ISPs:
$ ip route show table all | wc -l
3105543
$ ip route show table main | wc -l
54
Please let me know what other information I can provide, thanks in advance,
Jesse Hathaway
to know. Thanks, Jesse Hathaway
el as starting point to
finding when this problem was introduced. Please let me know if there is any
additional information I can provide or any test patches you would like me to
try. Thanks, Jesse Hathaway
Decoded stacktrace:
decode_stacktrace.sh was unable to decode the RIP line, but gdb was ab
