linux/include, branch v2.6.38.4

Bluetooth: Fix HCI_RESET command synchronization

2011-04-21T21:32:59Z

commit f630cf0d5434e3923e1b8226ffa2753ead6b0ce5 upstream. We can't send new commands before a cmd_complete for the HCI_RESET command shows up. Reported-by: Mikko Vinni Reported-by: Justin P. Mattock Reported-by: Ed Tomlinson Signed-off-by: Gustavo F. Padovan Tested-by: Justin P. Mattock Tested-by: Mikko Vinni Tested-by: Ed Tomlinson

next_pidmap: fix overflow condition

2011-04-21T21:32:52Z

commit c78193e9c7bcbf25b8237ad0dec82f805c4ea69b upstream. next_pidmap() just quietly accepted whatever 'last' pid that was passed in, which is not all that safe when one of the users is /proc. Admittedly the proc code should do some sanity checking on the range (and that will be the next commit), but that doesn't mean that the helper functions should just do that pidmap pointer arithmetic without checking the range of its arguments. So clamp 'last' to PID_MAX_LIMIT. The fact that we then do "last+1" doesn't really matter, the for-loop does check against the end of the pidmap array properly (it's only the actual pointer arithmetic overflow case we need to worry about, and going one bit beyond isn't going to overflow). [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ] Reported-by: Tavis Ormandy Analyzed-by: Robert Święcki Cc: Eric W. Biederman Cc: Pavel Emelyanov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

brk: COMPAT_BRK: fix detection of randomized brk

2011-04-21T21:32:49Z

commit 4471a675dfc7ca676c165079e91c712b09dc9ce4 upstream. 5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK") tried to get the whole logic of brk randomization for legacy (libc5-based) applications finally right. It turns out that the way to detect whether brk has actually been randomized in the end or not introduced by that patch still doesn't work for those binaries, as reported by Geert: : /sbin/init from my old m68k ramdisk exists prematurely. : : Before the patch: : : | brk(0x80005c8e) = 0x80006000 : : After the patch: : : | brk(0x80005c8e) = 0x80005c8e : : Old libc5 considers brk() to have failed if the return value is not : identical to the requested value. I don't like it, but currently see no better option than a bit flag in task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2 case. Signed-off-by: Jiri Kosina Tested-by: Geert Uytterhoeven Reported-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

kstrto*: converting strings to integers done (hopefully) right

2011-04-21T21:32:41Z

commit 33ee3b2e2eb9b4b6c64dcf9ed66e2ac3124e748c upstream. 1. simple_strto*() do not contain overflow checks and crufty, libc way to indicate failure. 2. strict_strto*() also do not have overflow checks but the name and comments pretend they do. 3. Both families have only "long long" and "long" variants, but users want strtou8() 4. Both "simple" and "strict" prefixes are wrong: Simple doesn't exactly say what's so simple, strict should not exist because conversion should be strict by default. The solution is to use "k" prefix and add convertors for more types. Enter kstrtoull() kstrtoll() kstrtoul() kstrtol() kstrtouint() kstrtoint() kstrtou64() kstrtos64() kstrtou32() kstrtos32() kstrtou16() kstrtos16() kstrtou8() kstrtos8() Include runtime testsuite (somewhat incomplete) as well. strict_strto*() become deprecated, stubbed to kstrto*() and eventually will be removed altogether. Use kstrto*() in code today! Note: on some archs _kstrtoul() and _kstrtol() are left in tree, even if they'll be unused at runtime. This is temporarily solution, because I don't want to hardcode list of archs where these functions aren't needed. Current solution with sizeof() and __alignof__ at least always works. Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

perf: Fix task context scheduling

2011-04-21T21:32:25Z

commit ab711fe08297de1485fff0a366e6db8828cafd6a upstream. Jiri reported: | | - once an event is created by sys_perf_event_open, task context | is created and it stays even if the event is closed, until the | task is finished ... thats what I see in code and I assume it's | correct | | - when the task opens event, perf_sched_events jump label is | incremented and following callbacks are started from scheduler | | __perf_event_task_sched_in | __perf_event_task_sched_out | | These callback *in/out set/unset cpuctx->task_ctx value to the | task context. | | - close is called on event on CPU 0: | - the task is scheduled on CPU 0 | - __perf_event_task_sched_in is called | - cpuctx->task_ctx is set | - perf_sched_events jump label is decremented and == 0 | - __perf_event_task_sched_out is not called | - cpuctx->task_ctx on CPU 0 stays set | | - exit is called on CPU 1: | - the task is scheduled on CPU 1 | - perf_event_exit_task is called | - task_ctx_sched_out unsets cpuctx->task_ctx on CPU 1 | - put_ctx destroys the context | | - another call of perf_rotate_context on CPU 0 will use invalid | task_ctx pointer, and eventualy panic. | Cure this the simplest possibly way by partially reverting the jump_label optimization for the sched_out case. Reported-and-tested-by: Jiri Olsa Signed-off-by: Peter Zijlstra Cc: Oleg Nesterov LKML-Reference: <1301520405.4859.213.camel@twins> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

atm/solos-pci: Don't flap VCs when carrier state changes

2011-04-14T20:02:39Z

commit c031235b395433350f25943b7580a5e343c7b7b2 upstream. Don't flap VCs when carrier state changes; higher-level protocols can detect loss of connectivity and act accordingly. This is more consistent with how other network interfaces work. We no longer use release_vccs() so we can delete it. release_vccs() was duplicated from net/atm/common.c; make the corresponding function exported, since other code duplicates it and could leverage it if it were public. Signed-off-by: Philip A. Prindeville Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: add some new ontario pci ids

2011-04-14T20:02:11Z

commit 758f231ea280d0e5f01d537f26ad8f5c0e3de1cc upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

net: fix ethtool->set_flags not intended -EINVAL return value

2011-04-14T20:02:11Z

commit 673e63c688f43104c73aad8ea4237f7ad41fa14d upstream. After commit d5dbda23804156ae6f35025ade5307a49d1db6d7 "ethtool: Add support for vlan accleration.", drivers that have NETIF_F_HW_VLAN_TX, and/or NETIF_F_HW_VLAN_RX feature, but do not allow enable/disable vlan acceleration via ethtool set_flags, always return -EINVAL from that function. Fix by returning -EINVAL only if requested features do not match current settings and can not be changed by driver. Change any driver that define ethtool->set_flags to use ethtool_invalid_flags() to avoid similar problems in the future (also on drivers that do not have the problem). Tested with modified (to reproduce this bug) myri10ge driver. Signed-off-by: Stanislaw Gruszka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ASoC: Explicitly say registerless widgets have no register

2011-04-14T20:02:06Z

commit 0ca03cd7d0fa3bfbd56958136a10f19733c4ce12 upstream. This stops code that handles widgets generically from attempting to access registers for these widgets. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman

PCI/ACPI: Report ASPM support to BIOS if not disabled from command line

2011-04-14T20:02:00Z

commit 8b8bae901ce23addbdcdb54fa1696fb2d049feb5 upstream. We need to distinguish the situation in which ASPM support is disabled from the command line or through .config from the situation in which it is disabled, because the hardware or BIOS can't handle it. In the former case we should not report ASPM support to the BIOS through ACPI _OSC, but in the latter case we should do that. Introduce pcie_aspm_support_enabled() that can be used by acpi_pci_root_add() to determine whether or not it should report ASPM support to the BIOS through _OSC. References: https://bugzilla.kernel.org/show_bug.cgi?id=29722 References: https://bugzilla.kernel.org/show_bug.cgi?id=20232 Reported-and-tested-by: Ortwin Glück Reviewed-by: Kenji Kaneshige Tested-by: Kenji Kaneshige Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman