[ovs-dev] [PATCH 2/3] lib/classifier: Simplify subtable array.

Ben Pfaff blp at nicira.com
Mon May 19 17:45:03 UTC 2014


On Mon, May 19, 2014 at 10:38:38AM -0700, Jarno Rajahalme wrote:
> 
> On May 19, 2014, at 7:48 AM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Fri, May 16, 2014 at 02:44:40PM -0700, Jarno Rajahalme wrote:
> >> Do not cache the 'tag' and 'max_priority' in the subtable array.  This
> >> makes later changes to classifier easier.
> >> 
> >> Also makes the 'cls_subtables*' functions to always leave the
> >> subtables array in a consistent state.  This includes the new
> >> cls_subtables_insert() function and removal of the old
> >> cls_subtables_push_back() function.
> >> 
> >> Signed-off-by: Jarno Rajahalme <jrajahalme at nicira.com>
> > 
> > The FOR_EACH macros caught my eye.  Each of them checks for a nonnull
> > pointer in the subtables array.  Are null pointers really possible?  I
> > took a quick look at the functions that modify the array and I did not
> > see how any of them could leave a null pointer in it.
> > 
> 
> I need to dereference the subtables array pointer only after the
> bounds check, otherwise I would be dereferencing a NULL pointer in
> case of an empty array, or potentially invalid memory after the end of
> the array. The dereference needs to produce a boolean true to keep the
> loop condition true, but maybe I could change it to the following
> instead:
> 
> #define CLS_SUBTABLES_FOR_EACH(SUBTABLE, ITER, SUBTABLES)  \
>     for ((ITER) = (SUBTABLES)->array;                      \
>          (ITER) < &(SUBTABLES)->array[(SUBTABLES)->count]  \
>              && ((SUBTABLE) = *(ITER), true);          \
>          ++(ITER))
> 
> i.e., ITER is dereferenced only after the successful bounds check, but
> the assigned value itself is not tested.

I would find that more straightforward because it does not imply that
the subtable pointers can be null, raising questions.

> > The code in cls_subtables_change_priority() has almost parallel code for
> > the two cases, except that in the new_priority < old_priority case it
> > does the iter++ before the break and in the other case it does the
> > iter-- after the loop.  I would prefer to make both cases the same.
> > 
> 
> To make both cases similar, I need to change the FOR_EACH macros to
> iterate using array indices, which turns out to be simpler anyway :-)

I was about to suggest that.

> I?ll send a v2.

Thanks,

Ben.



More information about the dev mailing list