linux/include, branch v2.6.16.56

[IA64] fix ia64 is_hugepage_only_range

2007-10-28T20:40:41Z

fix is_hugepage_only_range() definition to be "overlaps" instead of "within architectural restricted hugetlb address range". Simplify the ia64 specific code that used to use is_hugepage_only_range() to just check which region the address is in. Signed-off-by: Ken Chen Signed-off-by: Tony Luck Signed-off-by: Adrian Bunk

alpha: fix epoll syscall enumerations

2007-10-18T19:30:46Z

We went and named them __NR_sys_foo instead of __NR_foo. It may be too late to change this, but we can at least add the proper names now. Signed-off-by: Mike Frysinger Signed-off-by: Adrian Bunk

m68knommu: ptrace.h typo fix

2007-10-18T17:21:38Z

Signed-off-by: Jan Altenberg Signed-off-by: Adrian Bunk

[PKT_SCHED] RED: Fix overflow in calculation of queue average

2007-10-18T15:56:27Z

Overflow can occur very easily with 32 bits, e.g., with 1 second us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue length. Since the EWMA exponent is typically around 9, queue lengths larger than 2^2 cause overflow. Whether the affected branch is taken when us_idle is as high as 1 second, depends on Scell_log, but with rather reasonable configuration Scell_log is large enough to cause p->Stab to have zero index, which always results zero shift (typically also few other small indices result in zero shift). Signed-off-by: Ilpo Järvinen Signed-off-by: Adrian Bunk

sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses (CVE-2007-3104)

2007-10-06T22:52:10Z

Backport of ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/broken-out/gregkh-driver-sysfs-allocate-inode-number-using-ida.patch For regular files in sysfs, sysfs_readdir wants to traverse sysfs_dirent->s_dentry->d_inode->i_ino to get to the inode number. But, the dentry can be reclaimed under memory pressure, and there is no synchronization with readdir. This patch follows Tejun's scheme of allocating and storing an inode number in the new s_ino member of a sysfs_dirent, when dirents are created, and retrieving it from there for readdir, so that the pointer chain doesn't have to be traversed. Tejun's upstream patch uses a new-ish "ida" allocator which brings along some extra complexity; this -stable patch has a brain-dead incrementing counter which does not guarantee uniqueness, but because sysfs doesn't hash inodes as iunique expects, uniqueness wasn't guaranteed today anyway. Adrian Bunk: Backported to 2.6.16. Signed-off-by: Eric Sandeen Signed-off-by: Adrian Bunk

[SPARC]: fix sparc64 gcc 4.2 compile failure

2007-10-06T19:15:08Z

Compiling 2.6.21-rc5 with gcc-4.2.0 20070317 (prerelease) for sparc64 fails as follows: gcc -Wp,-MD,arch/sparc64/kernel/.time.o.d -nostdinc -isystem /home/mikpe/pkgs/linux-sparc64/gcc-4.2.0/lib/gcc/sparc64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Werror -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(time)" -D"KBUILD_MODNAME=KBUILD_STR(time)" -c -o arch/sparc64/kernel/time.o arch/sparc64/kernel/time.c cc1: warnings being treated as errors arch/sparc64/kernel/time.c: In function 'kick_start_clock': arch/sparc64/kernel/time.c:559: warning: overflow in implicit constant conversion make[1]: *** [arch/sparc64/kernel/time.o] Error 1 make: *** [arch/sparc64/kernel] Error 2 gcc gets unhappy when the MSTK_SET macro's u8 __val variable is updated with &= ~0xff (MSTK_YEAR_MASK). Making the constant unsigned fixes the problem. [ I fixed up the sparc32 side as well -DaveM ] Signed-off-by: Mikael Pettersson Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[MATH-EMU]: Fix underflow exception reporting.

2007-08-30T04:14:37Z

The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

md: avoid possible BUG_ON in md bitmap handling

2007-08-23T00:13:17Z

md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk

md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace

2007-08-22T23:37:54Z

.. so that you can use bitmaps with 32bit userspace on a 64 bit kernel. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk

md: fix resync speed calculation for restarted resyncs

2007-08-22T22:57:45Z

We introduced 'io_sectors' recently so we could count the sectors that causes io during resync separate from sectors which didn't cause IO - there can be a difference if a bitmap is being used to accelerate resync. However when a speed is reported, we find the number of sectors processed recently by subtracting an oldish io_sectors count from a current 'curr_resync' count. This is wrong because curr_resync counts all sectors, not just io sectors. So, add a field to mddev to store the curren io_sectors separately from curr_resync, and use that in the calculations. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk