Messages in this thread | | | Subject | Re: idr_get_new_above() limitation? | From | Jim Houston <> | Date | Mon, 02 Jul 2007 20:31:40 -0400 |
| |
On Mon, 2007-07-02 at 19:19 +0200, Hoang-Nam Nguyen wrote:
> i=3fffffff token=3fffffff t=000000003fffffff > i=40000000 token=40000000 t=0000000000000000 > Invalid object 0000000000000000. Expected 40000000 > > That means token 0x40000000 seems to be the "upper boundary" of idr_find(). > However the behaviour is not consistent in that it was returned by > idr_get_new_above().
Hi Nam,
Yes this is a bug. Thanks for the great test module.
The problem is in idr_get_new_above_int() in the loop which adds new layers to the top of the radix tree. It is failing the "layers < (MAX_LEVEL - 1)" test. It doesn't allocate the new layer but still calls sub_alloc() which relies on having the new layer properly constructed. I believe that it is allocating the slot which corresponds to id = 0.
I believe this is an off by one error in calculating the MAX_LEVEL value. I will do a more careful review and post a fix in the next day or so. I have been in Ottawa for OLS. I'm flying home tomorrow.
Jim Houston - Concurrent Computer Corp.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |