On Tue, 6 Jun 2006, Martin Schwidefsky wrote:
> On Tue, 2006-06-06 at 18:59 +0100, Hugh Dickins wrote:
> > Even s390 is okay, isn't it? MartinS's swp_type returns the highest
> > type, 31, corresponding to 32 types, as on every other architecture.
> > You and I and Martin Bligh would prefer this patch...
>
> As long as nobody will have the smart idea to increase MAX_SWAPFILES to
> more than 32 I'm fine with it.
Thanks, Martin: we know very well that we cannot increase MAX_SWAPFILES
without going through all the architectures adjusting their swap ptes
(and maybe making MAX_SWAPFILES_SHIFT per-arch), so I don't see any
problem there. But Christoph has observed that the comment becomes
out-of-date, so updated patch (adding your ack) below...
Remove unnecessary obfuscation from sys_swapon's range check on swap
type, which blew up causing memory corruption once swapless migration
made MAX_SWAPFILES no longer 2 ^ MAX_SWAPFILES_SHIFT.
Signed-off-by: Hugh Dickins <[email protected]>
Acked-by: Martin Schwidefsky <[email protected]>
--- 2.6.17-rc5-mm3/mm/swapfile.c 2006-06-04 11:52:47.000000000 +0100
+++ linux/mm/swapfile.c 2006-06-06 19:08:51.000000000 +0100
@@ -1392,19 +1392,7 @@ 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))))) {
+ if (type >= MAX_SWAPFILES) {
spin_unlock(&swap_lock);
goto out;
}
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
