Mark Tomlinson <[email protected]> wrote:
> When a new table value was assigned, it was followed by a write memory
> barrier. This ensured that all writes before this point would complete
> before any writes after this point. However, to determine whether the
> rules are unused, the sequence counter is read. To ensure that all
> writes have been done before these reads, a full memory barrier is
> needed, not just a write memory barrier. The same argument applies when
> incrementing the counter, before the rules are read.
>
> Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic
> reported in cc00bcaa5899,
Can you reproduce the crashes without this change?
> while still maintaining the same speed of replacing tables.
How much of an impact is the MB change on the packet path?
Please also CC authors of the patches you want reverted when reposting.
On Thu, 2021-03-04 at 08:46 +0100, Florian Westphal wrote:
> Mark Tomlinson <[email protected]> wrote:
> > Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic
> > reported in cc00bcaa5899,
>
> Can you reproduce the crashes without this change?
Yes. In our test environment we were seeing a kernel panic approx. twice
a day, with a similar output to that shown in Subash's patch (cc00bcaa5899).
With this patch we are not seeing any issue. The CPU is a dual-core ARM
Cortex-A9.
> > How much of an impact is the MB change on the packet path?
I will run our throughput tests and get these results.
I have a script which makes around 200 calls to iptables. This was taking
11.59s and now is back to 1.16s.