Thank you.
I applied this to master and backported it as far as branch-2.3.
On Wed, Dec 20, 2017 at 09:56:27AM -0800, Yifeng Sun wrote:
> Hi Ben,
>
> I think that simply moving up update_recirc_rules__ brings some confusion
> because if looking into update_recirc_rules__, at line 345, when bond-
Hi Ben,
I think that simply moving up update_recirc_rules__ brings some confusion
because if looking into update_recirc_rules__, at line 345, when bond->hash
is valid, update_recirc_rules__ may use bond->hash to invoke add_pr_rule.
I feel it is quite hard to figure out what is going on.
Thanks,
Y
On Mon, Dec 11, 2017 at 05:44:07AM -0800, Yifeng Sun wrote:
> pr_op->pr_rule is pointing to memory in bond->hash. It shouldn't be written
> if bond->hash is already freed.
>
> This bug is reported by running kernel path testsuite under valgrind:
> Invalid write of size 8
>at 0x413D16: update_r
On 12/11/2017 5:44 AM, Yifeng Sun wrote:
pr_op->pr_rule is pointing to memory in bond->hash. It shouldn't be written
if bond->hash is already freed.
This bug is reported by running kernel path testsuite under valgrind:
Invalid write of size 8
at 0x413D16: update_recirc_rules__ (bond.c:392)
pr_op->pr_rule is pointing to memory in bond->hash. It shouldn't be written
if bond->hash is already freed.
This bug is reported by running kernel path testsuite under valgrind:
Invalid write of size 8
at 0x413D16: update_recirc_rules__ (bond.c:392)
by 0x414CA0: bond_unref (bond.c:290)
by
