linux-toradex.git/include, branch v2.6.25.14

Correct hash flushing from huge_ptep_set_wrprotect()

2008-08-01T18:51:01+00:00

Correct hash flushing from huge_ptep_set_wrprotect() [stable tree version]

A fix for incorrect flushing of the hash page table at fork() for
hugepages was recently committed as
86df86424939d316b1f6cfac1b6204f0c7dee317.  Without this fix, a process
can make a MAP_PRIVATE hugepage mapping, then fork() and have writes
to the mapping after the fork() pollute the child's version.

Unfortunately this bug also exists in the stable branch.  In fact in
that case copy_hugetlb_page_range() from mm/hugetlb.c calls
ptep_set_wrprotect() directly, the hugepage variant hook
huge_ptep_set_wrprotect() doesn't even exist.

The patch below is a port of the fix to the stable25/master branch.
It introduces a huge_ptep_set_wrprotect() call, but this is #defined
to be equal to ptep_set_wrprotect() unless the arch defines its own
version and sets __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT.

This arch preprocessor flag is kind of nasty, but it seems the sanest
way to introduce this fix with minimum risk of breaking other archs
for whom prep_set_wprotect() is suitable for hugepages.

Signed-off-by: Andy Whitcroft 
Signed-off-by: David Gibson 
Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T18:50:58+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: fix fls() for 64-bit arguments

2008-08-01T18:50:47+00:00

commit 0c65f459ce6c8bd873a61b3ae1e57858ab1debf3 upstream

arm's fls() is implemented as a macro, causing it to misbehave when passed
64-bit arguments.  Fix.

Cc: Nickolay Vinogradov 
Tested-by: Krzysztof Halasa 
Signed-off-by: Andrew Morton 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

sparc64: Do not define BIO_VMERGE_BOUNDARY.

2008-08-01T18:50:43+00:00

[ Upstream commit 74988bd85d1cb97987534fd7ffbc570e81145418 ]

The IOMMU code and the block layer can split things
up using different rules, so this can't work reliably.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vmlinux.lds: move attribute((cold)) functions back into final .text section

2008-08-01T18:50:42+00:00

commit fb5e2b379732e1a6ea32392980bb42e0212db842 upstream

Due to the addition of __attribute__((__cold__)) to a few symbols
without adjusting the linker scripts, those symbols currently may end
up outside the [_stext,_etext) range, as they get placed in
.text.unlikely by (at least) gcc 4.3.0. This may confuse code not only
outside of the kernel, symbol_put_addr()'s BUG() could also trigger.
Hence we need to add .text.unlikely (and for future uses of
__attribute__((__hot__)) also .text.hot) to the TEXT_TEXT() macro.

Issue observed by Lukas Lipavsky.

Signed-off-by: Jan Beulich 
Tested-by: Lukas Lipavsky 
Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman

udplite: Protection against coverage value wrap-around

2008-07-28T17:58:18+00:00

[ Upstream commit 47112e25da41d9059626033986dc3353e101f815 ]

This patch clamps the cscov setsockopt values to a maximum of 0xFFFF.

Setsockopt values greater than 0xffff can cause an unwanted
wrap-around.  Further, IPv6 jumbograms are not supported (RFC 3838,
3.5), so that values greater than 0xffff are not even useful.

Further changes: fixed a typo in the documentation.

[ Add USHORT_MAX from upstream to linux/kernel.h -DaveM ]

Signed-off-by: Gerrit Renker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: KERNEL ifdef struct ipv6_devconf

2008-07-28T17:58:16+00:00

[ Upstream commit ebb36a978131810c98e7198b1187090c697cf99f ]

Based upon a report by Olaf Hering.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

block: Properly notify block layer of sync writes

2008-07-24T16:14:03+00:00

commit 18ce3751ccd488c78d3827e9f6bf54e6322676fb upstream

fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
then immediately wait on them. Conceptually, that makes them sync writes
and we should treat them as such so that the IO schedulers can handle
them appropriately.

This patch fixes a write starvation issue that Lin Ming reported, where
xx is stuck for more than 2 minutes because of a large number of
synchronous IO in the system:

INFO: task kjournald:20558 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
kjournald     D ffff810010820978  6712 20558      2
ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
Call Trace:
[] kobject_get+0x12/0x17
[] getnstimeofday+0x2f/0x83
[] sync_buffer+0x0/0x3f
[] io_schedule+0x5d/0x9f
[] sync_buffer+0x3b/0x3f
[] __wait_on_bit+0x40/0x6f
[] sync_buffer+0x0/0x3f
[] out_of_line_wait_on_bit+0x6c/0x78
[] wake_bit_function+0x0/0x23
[] sync_dirty_buffer+0x98/0xcb
[] journal_commit_transaction+0x97d/0xcb6
[] lock_timer_base+0x26/0x4b
[] kjournald+0xc1/0x1fb
[] autoremove_wake_function+0x0/0x2e
[] kjournald+0x0/0x1fb
[] kthread+0x47/0x74
[] schedule_tail+0x28/0x5d
[] child_rip+0xa/0x12
[] kthread+0x0/0x74
[] child_rip+0x0/0x12

Lin Ming confirms that this patch fixes the issue. I've run tests with
it for the past week and no ill effects have been observed, so I'm
proposing it for inclusion into 2.6.26.

Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

x86: fix ldt limit for 64 bit

2008-07-13T17:54:09+00:00

commit 5ac37f87ff18843aabab84cf75b2f8504c2d81fe upstream

Fix size of LDT entries. On x86-64, ldt_desc is a double-sized descriptor.

Signed-off-by: Michael Karcher 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: shift bits the right way in native_read_tscp

2008-07-03T03:46:16+00:00

Commit 41aefdcc98fdba47459eab67630293d67e855fc3 upstream

x86: shift bits the right way in native_read_tscp

native_read_tscp shifts the bits in the high order value in the
wrong direction, the attached patch fixes that.

Signed-off-by: Max Asbock 
Acked-by: Glauber Costa 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman