All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: jim.houston@comcast.net
Cc: kevcorry@us.ibm.com, linux-kernel@vger.kernel.org,
	dm-devel@redhat.com, torvalds@osdl.org, agk@redhat.com
Subject: Re: [PATCH] 1/1: Device-Mapper: Remove 1024 devices limitation
Date: Tue, 6 Jul 2004 16:16:41 -0700	[thread overview]
Message-ID: <20040706161641.01c1bbce.akpm@osdl.org> (raw)
In-Reply-To: <1089154845.985.164.camel@new.localdomain>

Jim Houston <jim.houston@comcast.net> wrote:
>
> With out the test above an id beyond the allocated space will alias
> to one that exists.  Perhaps the highest id currently allocated is 
> 100, there will be two layers in the radix tree and the while loop
> above will only look at the 10 least significant bits.  If you call
> idr_find with 1025 it will return the pointer associated with id 1.

OK.

> The patch I sent was against linux-2.6.7, so I missed the change to
> MAX_ID_SHIFT.

How about this?

diff -puN lib/idr.c~idr-stale-comment lib/idr.c
--- 25/lib/idr.c~idr-stale-comment	Tue Jul  6 16:12:45 2004
+++ 25-akpm/lib/idr.c	Tue Jul  6 16:15:41 2004
@@ -27,22 +27,6 @@
  * so you don't need to be too concerned about locking and conflicts
  * with the slab allocator.
 
- * What you need to do is, since we don't keep the counter as part of
- * id / ptr pair, to keep a copy of it in the pointed to structure
- * (or else where) so that when you ask for a ptr you can varify that
- * the returned ptr is correct by comparing the id it contains with the one
- * you asked for.  In other words, we only did half the reuse protection.
- * Since the code depends on your code doing this check, we ignore high
- * order bits in the id, not just the count, but bits that would, if used,
- * index outside of the allocated ids.  In other words, if the largest id
- * currently allocated is 32 a look up will only look at the low 5 bits of
- * the id.  Since you will want to keep this id in the structure anyway
- * (if for no other reason than to be able to eliminate the id when the
- * structure is found in some other way) this seems reasonable.  If you
- * really think otherwise, the code to check these bits here, it is just
- * disabled with a #if 0.
-
-
  * So here are the complete details:
 
  *  include <linux/idr.h>
@@ -371,15 +355,11 @@ void *idr_find(struct idr *idp, int id)
 	struct idr_layer *p;
 
 	n = idp->layers * IDR_BITS;
+	if (id >= (1 << n))
+		return NULL;
+
 	p = idp->top;
-#if 0
-	/*
-	 * This tests to see if bits outside the current tree are
-	 * present.  If so, tain't one of ours!
-	 */
-	if ( unlikely( (id & ~(~0 << MAX_ID_SHIFT)) >> (n + IDR_BITS)))
-	     return NULL;
-#endif
+
 	/* Mask off upper bits we don't use for the search. */
 	id &= MAX_ID_MASK;
 
_


  reply	other threads:[~2004-07-06 23:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-01 15:35 [PATCH] 1/1: Device-Mapper: Remove 1024 devices limitation Kevin Corry
2004-07-01 21:38 ` Andrew Morton
2004-07-02  2:54   ` Kevin Corry
2004-07-02  3:30     ` Andrew Morton
2004-07-02 17:33       ` Kevin Corry
2004-07-02 19:42         ` Andrew Morton
2004-07-06 18:23           ` Kevin Corry
2004-07-06 21:23             ` Andrew Morton
2004-07-06 21:35               ` Alasdair G Kergon
2004-07-06 22:04                 ` Alasdair G Kergon
2004-07-06 22:20                 ` Andrew Morton
2004-07-06 22:07               ` Jim Houston
2004-07-06 22:28                 ` Andrew Morton
2004-07-06 23:00                   ` Jim Houston
2004-07-06 23:16                     ` Andrew Morton [this message]
2004-07-07 10:58                       ` Jim Houston
2004-07-07 11:10                         ` Andrew Morton
2004-07-12 14:49                           ` Kevin Corry
2004-07-12 18:14                             ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040706161641.01c1bbce.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jim.houston@comcast.net \
    --cc=kevcorry@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.