kernel/linux.git/include/linux, branch linux-2.6.16.y

moduleparam: fix alpha, ia64 and ppc64 compile failures

2008-07-19T12:57:03+00:00

On alpha, ia64 and ppc64 only relocations to local data can go into read-only sections. The vast majority of module parameters use the global generic param_set_*/param_get_* functions, so the 'const' attribute for struct kernel_param is not only useless, but it also causes compile failures due to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky Signed-off-by: Adrian Bunk

gcc >= 4.3 is not supported

2008-03-14T20:05:58+00:00

Building kernel 2.6.16 with gcc 4.3 is completely untested, and you might run into both kernel and gcc problems (as always with new gcc versions). For making this obvious the kernel build now #error's when trying to build with gcc >= 4.3. The kernel might work fine when compiled with gcc 4.3 and it's therefore possible to remove the #error, but if someone really longs for regressions he can as well try a more recent kernel instead. Signed-off-by: Adrian Bunk

[NET]: Introduce types for checksums.

2008-01-20T20:05:18+00:00

New types - for 16bit checksums and "unfolded" 32bit variant. Signed-off-by: Al Viro Signed-off-by: Adrian Bunk

struct input_device_id mustn't be userspace visible

2008-01-15T22:44:33+00:00

struct input_device_id mustn't be userspace visible since it uses kernel_ulong_t. Signed-off-by: Adrian Bunk

[NETLINK]: Fix unicast timeouts

2007-11-13T11:23:22+00:00

[ Upstream commit: c3d8d1e30cace31fed6186a4b8c6b1401836d89c ] Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts by moving the schedule_timeout() call to a new function that doesn't propagate the remaining timeout back to the caller. This means on each retry we start with the full timeout again. ipc/mqueue.c seems to actually want to wait indefinitely so this behaviour is retained. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

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

2007-10-06T22:52:10+00:00

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

md: avoid possible BUG_ON in md bitmap handling

2007-08-23T00:13:17+00:00

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:54+00:00

.. 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:45+00:00

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

md/bitmap: remove dead code from md/bitmap

2007-08-11T23:07:37+00:00

bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or tested, so discard them both. Also remove some out-of-date 'todo' comments. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk