Re: 2.6.17-rc5-mm1

[Christoph Lameter]

> Either way, random panics are not the appropriate response ;-)
> 
> if it can't cope with that, why isn't it failing the request ???

There is a crappy test in swap_on(). It should check against MAX_SWAPFILES 
and not do this conversion back and forth. Some architectures may not 
check if we are beyond the boundaries of what a swap entry can take.

Why is this strange this in there? Are there architectures that support 
less than 32 swap devices?

Signed-off-by: Christoph Lameter <clameter@xxxxxxx>

Index: linux-2.6.17-rc5-mm2/mm/swapfile.c
===================================================================
--- linux-2.6.17-rc5-mm2.orig/mm/swapfile.c	2006-06-01 10:03:07.127259731 -0700
+++ linux-2.6.17-rc5-mm2/mm/swapfile.c	2006-06-05 13:24:56.000823157 -0700
@@ -1384,6 +1384,9 @@ asmlinkage long sys_swapon(const char __
 	struct inode *inode = NULL;
 	int did_down = 0;
 
+	if (nr_swapfiles >= MAX_SWAPFILES)
+		return -E2BIG;
+
 	if (!capable(CAP_SYS_ADMIN))
 		return -EPERM;
 	spin_lock(&swap_lock);
@@ -1392,22 +1395,6 @@ asmlinkage long sys_swapon(const char __
 		if (!(p->flags & SWP_USED))
 			break;
 	error = -EPERM;
-	/*
-	 * Test if adding another swap device is possible. There are
-	 * two limiting factors: 1) the number of bits for the swap
-	 * type swp_entry_t definition and 2) the number of bits for
-	 * the swap type in the swap ptes as defined by the different
-	 * architectures. To honor both limitations a swap entry
-	 * with swap offset 0 and swap type ~0UL is created, encoded
-	 * to a swap pte, decoded to a swp_entry_t again and finally
-	 * the swap type part is extracted. This will mask all bits
-	 * from the initial ~0UL that can't be encoded in either the
-	 * swp_entry_t or the architecture definition of a swap pte.
-	 */
-	if (type > swp_type(pte_to_swp_entry(swp_entry_to_pte(swp_entry(~0UL,0))))) {
-		spin_unlock(&swap_lock);
-		goto out;
-	}
 	if (type >= nr_swapfiles)
 		nr_swapfiles = type+1;
 	INIT_LIST_HEAD(&p->extent_list);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/