Thx for the reminding,
I checked the branch-2.3 code, we use rwlock to protect the classifier
add/remove/lookup on ofproto level and dpif-netdev level.
So, I think we are fine there,
Alex Wang,
On Wed, Oct 1, 2014 at 1:10 PM, Ben Pfaff wrote:
> Does it need to be backported?
>
> On Wed, Oct
Does it need to be backported?
On Wed, Oct 01, 2014 at 01:03:11PM -0700, Alex Wang wrote:
> Thx for the review, applied to master,~
>
> On Wed, Oct 1, 2014 at 12:52 PM, Ben Pfaff wrote:
>
> > On Wed, Oct 01, 2014 at 12:03:30PM -0700, Alex Wang wrote:
> > > Currently, the cmap_destroy() directly
Thx for the review, applied to master,~
On Wed, Oct 1, 2014 at 12:52 PM, Ben Pfaff wrote:
> On Wed, Oct 01, 2014 at 12:03:30PM -0700, Alex Wang wrote:
> > Currently, the cmap_destroy() directly frees the cmap memory.
> > Some callers of cmap_destroy() (e.g. destroy_subtable()) still
> > allows o
On Wed, Oct 01, 2014 at 12:03:30PM -0700, Alex Wang wrote:
> Currently, the cmap_destroy() directly frees the cmap memory.
> Some callers of cmap_destroy() (e.g. destroy_subtable()) still
> allows other threads (e.g. pmd threads) accessing the cmap at
> the same time (e.g. via classifier_lookup_min
Currently, the cmap_destroy() directly frees the cmap memory.
Some callers of cmap_destroy() (e.g. destroy_subtable()) still
allows other threads (e.g. pmd threads) accessing the cmap at
the same time (e.g. via classifier_lookup_miniflow_batch()),
which could cause segfault.
To fix the above issue
