I wrote:
>
> The proc_alloc_map bitfield is unprotected by any lock, and
> find_first_zero_bit() is not atomic. Concurrent module loading can race
> here.
Hello,
Here is a patch for this. It looks like callers are always in user context
(kmalloc flag GFP_KERNEL), so I used a light spinlock.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
--- linux-2.4.3/fs/proc/generic.c.orig Thu Apr 5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c Thu Apr 5 10:22:48 2001
@@ -192,13 +192,22 @@
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
static int make_inode_number(void)
{
- int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
- if (i<0 || i>=PROC_NDYNAMIC)
- return -1;
+ int i;
+ spin_lock(&proc_alloc_map_lock);
+ i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+ if (i<0 || i>=PROC_NDYNAMIC) {
+ i = -1;
+ goto out;
+ }
set_bit(i, (void *) proc_alloc_map);
- return PROC_DYNAMIC_FIRST + i;
+ i += PROC_DYNAMIC_FIRST;
+out:
+ spin_unlock(&proc_alloc_map_lock);
+ return i;
}
static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
