> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH for-2.6.22] IB/cm: improve local id allocation
> 
>  > A quick looks makes it look like idr stuff is *really* not designed to
>  > get a negative input: and note that old code has the wrap-around problem, 
> too.
>  > So, I think the following would be a better fix:
> 
> Yes, that's basically what I just proposed (although see below).  It
> all looks pretty safe to me...  Sean, what do you think about this for
> 2.6.22?
> 
>  > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
>  > index eff591d..5e77b01 100644
>  > --- a/drivers/infiniband/core/cm.c
>  > +++ b/drivers/infiniband/core/cm.c
>  > @@ -306,7 +306,9 @@ static int cm_alloc_id(struct cm_id_private 
> *cm_id_priv)
>  >    do {
>  >            spin_lock_irqsave(&cm.lock, flags);
>  >            ret = idr_get_new_above(&cm.local_id_table, cm_id_priv,
>  > -                                  next_id++, &id);
>  > +                                  next_id, &id);
>  > +          if (!ret)
>  > +                  next_id = id == 0x7ffffff ? 0 : id + 1;
> 
> ...except I used MAX_INT here, and indeed your patch only has 6 'f's
> in that constant.  Actually digging a little I see that we should use
> MAX_ID_MASK to be really correct.

And since it's a *mask*, we can do it this way if you like:

>  > +          if (!ret)
>  > +                  next_id = ((unsigned)id + 1) & MAX_ID_MASK;

which might generate a bit less code.

-- 
MST
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to