commit 48ae1731f8a9354f0115a836d9a37d767c814060
Author: Anand H. Krishnan <email address hidden>
Date: Mon Dec 7 11:21:47 2015 +0530
Before initiating eviction, set M(odified) flag
Currently, before evicting the forward flow, we get to the reverse
flow and mark it for eviction. Then we go on to mark forward flow
for eviction and schedule the eviction at a later time. It is in
this deferred functionality that is scheduled that the forward and
the reverse flow gets evicted. We set the M(odified) flag at the
time of 'eviction-marking' in each of the flow entries so that
subsequent changes to the flow entry is not honoured.
It is possible that the forward flow can undergo a change in which
its reverse flow is unlinked (or changed) while the reverse flow
was in the process of getting marked for eviction. If that happens,
at the time of actual eviction, the deferred call will not be able
to find the reverse flow from the forward flow and the reverse flow
will remain in the 'Eviction-Candidate' state forever.
To fix this race, mark the forward flow as M(odified) before
initiating the eviction process, making sure that the mapping between
the forward and the reverse flow is untouched once eviction process
is initiated.
Reviewed: https:/ /review. opencontrail. org/15825 github. org/Juniper/ contrail- vrouter/ commit/ 48ae1731f8a9354 f0115a836d9a37d 767c814060
Committed: http://
Submitter: Zuul
Branch: master
commit 48ae1731f8a9354 f0115a836d9a37d 767c814060
Author: Anand H. Krishnan <email address hidden>
Date: Mon Dec 7 11:21:47 2015 +0530
Before initiating eviction, set M(odified) flag
Currently, before evicting the forward flow, we get to the reverse
flow and mark it for eviction. Then we go on to mark forward flow
for eviction and schedule the eviction at a later time. It is in
this deferred functionality that is scheduled that the forward and
the reverse flow gets evicted. We set the M(odified) flag at the
time of 'eviction-marking' in each of the flow entries so that
subsequent changes to the flow entry is not honoured.
It is possible that the forward flow can undergo a change in which Candidate' state forever.
its reverse flow is unlinked (or changed) while the reverse flow
was in the process of getting marked for eviction. If that happens,
at the time of actual eviction, the deferred call will not be able
to find the reverse flow from the forward flow and the reverse flow
will remain in the 'Eviction-
To fix this race, mark the forward flow as M(odified) before
initiating the eviction process, making sure that the mapping between
the forward and the reverse flow is untouched once eviction process
is initiated.
Change-Id: I088ac3abd5c3bf c7bf77efc697bbe 1386254358f
Closes-BUG: 1521496