> 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.
_______________________________________________
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
