linux/include, branch v2.6.23.4

Fix netlink timeouts.

2007-11-16T16:27:38Z

[NETLINK]: Fix unicast timeouts [ 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: Greg Kroah-Hartman

TCP: Fix size calculation in sk_stream_alloc_pskb

2007-11-16T16:27:36Z

[TCP]: Fix size calculation in sk_stream_alloc_pskb [ Upstream commit: fb93134dfc2a6e6fbedc7c270a31da03fce88db9 ] We round up the header size in sk_stream_alloc_pskb so that TSO packets get zero tail room. Unfortunately this rounding up is not coordinated with the select_size() function used by TCP to calculate the second parameter of sk_stream_alloc_pskb. As a result, we may allocate more than a page of data in the non-TSO case when exactly one page is desired. In fact, rounding up the head room is detrimental in the non-TSO case because it makes memory that would otherwise be available to the payload head room. TSO doesn't need this either, all it wants is the guarantee that there is no tail room. So this patch fixes this by adjusting the skb_reserve call so that exactly the requested amount (which all callers have calculated in a precise way) is made available as tail room. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix SKB_WITH_OVERHEAD calculations.

2007-11-16T16:27:36Z

patch deea84b0ae3d26b41502ae0a39fe7fe134e703d0 in mainline. [NET]: Fix SKB_WITH_OVERHEAD calculation The calculation in SKB_WITH_OVERHEAD is incorrect in that it can cause an overflow across a page boundary which is what it's meant to prevent. In particular, the header length (X) should not be lumped together with skb_shared_info. The latter needs to be aligned properly while the header has no choice but to sit in front of wherever the payload is. Therefore the correct calculation is to take away the aligned size of skb_shared_info, and then subtract the header length. The resulting quantity L satisfies the following inequality: SKB_DATA_ALIGN(L + X) + sizeof(struct skb_shared_info) <= PAGE_SIZE This is the quantity used by alloc_skb to do the actual allocation. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix 9P protocol build

2007-11-16T16:27:36Z

patch 092e9d93b3728d484a4e73df9852dc4002cf9923 in mainline. [9P]: build fix with !CONFIG_SYSCTL found via make randconfig build testing: net/built-in.o: In function `init_p9': mod.c:(.init.text+0x3b39): undefined reference to `p9_sysctl_register' net/built-in.o: In function `exit_p9': mod.c:(.exit.text+0x36b): undefined reference to `p9_sysctl_unregister' Signed-off-by: Ingo Molnar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-16T16:22:59Z

Reverted upstream by commit 6a22c57b8d2a62dea7280a6b2ac807a539ef0716 Revert this commit: commit 2e1c49db4c640b35df13889b86b9d62215ade4b6 Author: Zou Nan hai Date: Fri Jun 1 00:46:28 2007 -0700 x86_64: allocate sparsemem memmap above 4G This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6. First off, testing in Fedora has shown it to cause boot failures, bisected down by Martin Ebourne, and reported by Dave Jobes. So the commit will likely be reverted in the 2.6.23 stable kernels. Secondly, in the 2.6.24 model, x86-64 has now grown support for SPARSEMEM_VMEMMAP, which disables the relevant code anyway, so while the bug is not visible any more, it's become invisible due to the code just being irrelevant and no longer enabled on the only architecture that this ever affected. Reported-by: Dave Jones Tested-by: Martin Ebourne Cc: Zou Nan hai Cc: Suresh Siddha Cc: Andrew Morton Acked-by: Andy Whitcroft Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

xen: fix incorrect vcpu_register_vcpu_info hypercall argument

2007-11-16T16:22:58Z

patch e3d2697669abbe26c08dc9b95e2a71c634d096ed in mainline. The kernel's copy of struct vcpu_register_vcpu_info was out of date, at best causing the hypercall to fail and the guest kernel to fall back to the old mechanism, or worse, causing random memory corruption. Signed-off-by: Jeremy Fitzhardinge Cc: Stable Kernel Cc: Morten =?utf-8?q?B=C3=B8geskov?= Cc: Mark Williamson Signed-off-by: Greg Kroah-Hartman

MIPS: R1: Fix hazard barriers to make kernels work on R2 also.

2007-11-16T16:22:56Z

patch 572afc248c33c902760f6f24a72c180f0e4f1719 in mainline. Tested with Malta; inflates malta_defconfig by 3932 bytes. Ideally there should be additional configuration to allow getting rid of this overhead but that would be too much complexity at this stage of the release cycle. Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps

2007-11-16T16:12:44Z

patch 6eca9004dfcb274a502438a591df5b197690afb1 in mainline. For the locking to work, only the tag map and tag bit map may be shared (incidentally, I was just explaining this to Nick yesterday, but I apparently didn't review the code well enough myself). But we also share the busy list! The busy_list must be queue private, or we need a block_queue_tag covering lock as well. So we have to move the busy_list to the queue. This'll work fine, and it'll actually also fix a problem with blk_queue_invalidate_tags() which will invalidate tags across all shared queues. This is a bit confusing, the low level driver should call it for each queue seperately since otherwise you cannot kill tags on just a single queue for eg a hard drive that stops responding. Since the function has no callers currently, it's not an issue. This is fixed with commit 6eca9004dfcb274a502438a591df5b197690afb1 in Linus' tree. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

sched: keep utime/stime monotonic

2007-11-16T16:12:44Z

sched: keep utime/stime monotonic cpustats use utime/stime as a ratio against sum_exec_runtime, as a consequence it can happen - when the ratio changes faster than time accumulates - that either can be appear to go backwards. Combined backport for 2.6.23 of the following patches from mainline: commit 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee Author: Peter Zijlstra sched: keep utime/stime monotonic commit 9301899be75b464ef097f0b5af7af6d9bd8f68a7 Author: Balbir Singh sched: fix /proc//stat stime/utime monotonicity, part 2 Signed-off-by: Frans Pop CC: Peter Zijlstra CC: Balbir Singh Signed-off-by: Greg Kroah-Hartman

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2007-10-08T19:59:10Z

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [IPv6]: Fix ICMPv6 redirect handling with target multicast address [PKT_SCHED] cls_u32: error code isn't been propogated properly [ROSE]: Fix rose.ko oops on unload [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed