Not really (though the clarity and reassurance of the additional
MAX_SWAPFILES test is good). We went over it a year or two back,
and the macro contortions do involve MAX_SWAPFILES_SHIFT: which
up to and including 2.6.17 has enforced the MAX_SWAPFILES limit.
It looks though as if the testers were able to define more than 32 swap
devices. So there is the danger of overwriting the memory
following the swap info if we do not fix this.
Where are the macro contortions? No arch uses MAX_SWAPFILES_SHIFT for its
definitions and the only other significant use is in swapops.h to
determine the shift.
I'll go mad if I try to work it out again: I was as worried as you
when I discovered that test in sys_swapon a year or so ago, apparently
without any check on MAX_SWAPFILES; and went moaning to Andrew. But
once I'd worked through swp_type, pte_to_swp_entry, swp_entry_to_pte,
swp_entry, I did come to the conclusion that the MAX_SWAPFILES bound
was actually safely built in there.
If it's that difficult to figure out, is that not reason enough to rip
it all out and replace it? ;-) Life seems quite complicated enough as
it is.
M.
-
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]
