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

net: Fix recursive descent in __scm_destroy().

2008-11-10T18:50:05+00:00

commit f8d570a4745835f2238a33b537218a1bb03fc671 and
3b53fbf4314594fa04544b02b2fc6e607912da18 upstream (because once wasn't
good enough...)

__scm_destroy() walks the list of file descriptors in the scm_fp_list
pointed to by the scm_cookie argument.

Those, in turn, can close sockets and invoke __scm_destroy() again.

There is nothing which limits how deeply this can occur.

The idea for how to fix this is from Linus.  Basically, we do all of
the fput()s at the top level by collecting all of the scm_fp_list
objects hit by an fput().  Inside of the initial __scm_destroy() we
keep running the list until it is empty.

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

clockevents: prevent clockevent event_handler ending up handler_noop

2008-10-09T02:44:41+00:00

commit 7c1e76897492d92b6a1c2d6892494d39ded9680c upstream

There is a ordering related problem with clockevents code, due to which
clockevents_register_device() called after tickless/highres switch
will not work. The new clockevent ends up with clockevents_handle_noop as
event handler, resulting in no timer activity.

The problematic path seems to be

* old device already has hrtimer_interrupt as the event_handler
* new clockevent device registers with a higher rating
* tick_check_new_device() is called
  * clockevents_exchange_device() gets called
    * old->event_handler is set to clockevents_handle_noop
  * tick_setup_device() is called for the new device
    * which sets new->event_handler using the old->event_handler which is noop.

Change the ordering so that new device inherits the proper handler.

This does not have any issue in normal case as most likely all the clockevent
devices are setup before the highres switch. But, can potentially be affecting
some corner case where HPET force detect happens after the highres switch.
This was a problem with HPET in MSI mode code that we have been experimenting
with.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Shaohua Li 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

fbdefio: add set_page_dirty handler to deferred IO FB

2008-09-08T10:20:17+00:00

commit d847471d063663b9f36927d265c66a270c0cfaab upstream

Fixes kernel BUG at lib/radix-tree.c:473.

Previously the handler was incidentally provided by tmpfs but this was
removed with:

  commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1
  Author: Hugh Dickins 
  Date:   Mon Jul 28 15:46:19 2008 -0700

    tmpfs: fix kernel BUG in shmem_delete_inode

relying on this behaviour was incorrect in any case and the BUG also
appeared when the device node was on an ext3 filesystem.

v2: override a_ops at open() time rather than mmap() time to minimise
races per AKPM's concerns.

Signed-off-by: Ian Campbell 
Cc: Jaya Kumar 
Cc: Nick Piggin 
Cc: Peter Zijlstra 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Jeremy Fitzhardinge 
Cc: Kel Modderman 
Cc: Markus Armbruster 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

usb-serial: don't release unregistered minors

2008-08-20T18:15:20+00:00

commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream

This patch (as1121) fixes a bug in the USB serial core.  When a device
is unregistered, the core will give back its minors -- even if the
device hasn't been assigned any!

The patch reserves the highest minor value (255) to mean that no minor
was assigned.  It also removes some dead code and does a small style
fixup.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

FAT_VALID_MEDIA(): remove pointless test

2008-08-06T17:11:01+00:00

commit 73f20e58b1d586e9f6d3ddc3aad872829aca7743 upstream

The on-disk media specification field in FAT is only 8-bits, so testing for
<=0xff is pointless, and can generate a "comparison is always true due to
limited range of data type" warning.

While we're there, convert FAT_VALID_MEDIA() into a C function - the present
implementation is buggy: it generates either one or two references to its
argument.

Cc: Frank Seidel 
Acked-by: OGAWA Hirofumi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
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

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

Add return value to reserve_bootmem_node()

2008-06-24T21:08:29+00:00

commit 71c2742f5e6348d76ee62085cf0a13e5eff0f00e upstream

This patch changes the function reserve_bootmem_node() from void to int,
returning -ENOMEM if the allocation fails.

This fixes a build problem on x86 with CONFIG_KEXEC=y and
CONFIG_NEED_MULTIPLE_NODES=y

Signed-off-by: Bernhard Walle 
Reported-by: Adrian Bunk 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman