lkml.org 
[lkml]   [2004]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 1/1: Device-Mapper: Remove 1024 devices limitation
Jim Houston <jim.houston@comcast.net> wrote:
>
> On Tue, 2004-07-06 at 17:23, Andrew Morton wrote:
> > Kevin Corry <kevcorry@us.ibm.com> wrote:
> > >
> > > After talking with Alasdair a bit, there might be one bug in the "dm-use-idr"
> > > patch I submitted before. It seems (based on some comments in lib/idr.c) that
> > > the idr_find() routine might not return NULL if the desired ID value is not
> > > in the tree.
> >
> >
> > Confused. idr_find() returns the thing it found, or NULL. To which
> > comments do you refer?
>
> Hi Andrew, Kevin,
>
> Kevin is correct. It's more of the nonsense related to having a counter
> in the upper bits of the id. If you call idr_find with an id that is
> beyond the currently allocated space it ignores the upper bits and
> returns one of the entries that is in the allocated space. This
> aliasing is most annoying.

erk, OK, we have vestigial bits still. Note that MAX_ID_SHIFT is now 31 on
32-bit, so we're still waggling the top bit.

> I'm attaching an untested patch which removes the counter in the upper
> bits of the id and makes idr_find return NULL if the requested id is
> beyond the allocated space.

Would you have time to get it tested please?

> I suspect that there are problems with
> id values which are less than zero.

Me too. I'd only be confident in the 0..2G range.


> -#endif
> + if (id >= (1 << n))
> + return NULL;
> while (n > 0 && p) {
> n -= IDR_BITS;
> p = p->ary[(id >> n) & IDR_MASK];
>

I think the above test is unneeded?
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.065 / U:3.372 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site