user/sven/linux.git/include, branch v2.6.35.4

tracing: Fix timer tracing

2010-08-26T23:46:32Z

commit ede1b4290781ae82ccf0f2ecc6dada8d3dd35779 upstream. PowerTOP would like to be able to trace timers. Unfortunately, the current timer tracing is not very useful: the actual timer function is not recorded in the trace at the start of timer execution. Although this is recorded for timer "start" time (when it gets armed), this is not useful; most timers get started early, and a tracer like PowerTOP will never see this event, but will only see the actual running of the timer. This patch just adds the function to the timer tracing; I've verified with PowerTOP that now it can get useful information about timers. Signed-off-by: Arjan van de Ven Cc: xiaoguangrong@cn.fujitsu.com Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Peter Zijlstra LKML-Reference: <4C6C5FA9.3000405@linux.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

can-raw: Fix skb_orphan_try handling

2010-08-26T23:46:18Z

commit cff0d6e6edac7672b3f915bb4fb59f279243b7f9 upstream. Commit fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5 (net: Introduce skb_orphan_try()) allows an early orphan of the skb and takes care on tx timestamping, which needs the sk-reference in the skb on driver level. So does the can-raw socket, which has not been taken into account here. The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info, which fixes the problem discovered by Matthias Fuchs here: http://marc.info/?t=128030411900003&r=1&w=2 Even if it's not a primary tx timestamp topic it fits well into some skb shared tx context. Or should be find a different place for the information to protect the sk reference until it reaches the driver level? Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Fix init ordering of /dev/console vs callers of modprobe

2010-08-26T23:46:04Z

commit 31d1d48e199e99077fb30f6fb9a793be7bec756f upstream. Make /dev/console get initialised before any initialisation routine that invokes modprobe because if modprobe fails, it's going to want to open /dev/console, presumably to write an error message to. The problem with that is that if the /dev/console driver is not yet initialised, the chardev handler will call request_module() to invoke modprobe, which will fail, because we never compile /dev/console as a module. This will lead to a modprobe loop, showing the following in the kernel log: request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 This can happen, for example, when the built in md5 module can't find the built in cryptomgr module (because the latter fails to initialise). The md5 module comes before the call to tty_init(), presumably because 'crypto' comes before 'drivers' alphabetically. Fix this by calling tty_init() from chrdev_init(). Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mm: make the vma list be doubly linked

2010-08-26T23:45:56Z

commit 297c5eee372478fc32fec5fe8eed711eedb13f3d upstream. It's a really simple list, and several of the users want to go backwards in it to find the previous vma. So rather than have to look up the previous entry with 'find_vma_prev()' or something similar, just make it doubly linked instead. Tested-by: Ian Campbell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mtd: change struct flchip_shared spinlock locking into mutex

2010-08-26T23:45:54Z

commit 8ae664184c45def51ff0b61d4bd6c6671db6cb4f upstream. This patch prevent to schedule while atomic by changing the flchip_shared spinlock into a mutex. This should be save since no atomic path will use this lock. It was suggested by Arnd Bergmann and Vasiliy Kulikov. Signed-off-by: Stefani Seibold Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)

2010-08-26T23:45:45Z

commit 56385a12d9bb9e173751f74b6c430742018cafc0 upstream. With some hardware combinations, the PCM interrupts are acknowledged before the period boundary from the emu10k1 chip. The midlevel PCM code gets confused and the playback stream is interrupted. It seems that the interrupt processing shift by 2 samples is enough to fix this issue. This default value does not harm other, non-affected hardware. More information: Kernel bugzilla bug#16300 [A copmile warning fixed by tiwai] Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

acpi: fix bogus preemption logic

2010-08-26T23:45:43Z

commit 0a7992c90828a65281c3c9cf180be3b432d277b2 upstream. The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d (ACPICA: add preemption point after each opcode parse). The follow up commits abe1dfab6, 138d15692, c084ca70 tried to fix the preemption logic back and forth, but nobody noticed that the usage of in_atomic_preempt_off() in that context is wrong. The check which guards the call of cond_resched() is: if (!in_atomic_preempt_off() && !irqs_disabled()) in_atomic_preempt_off() is not intended for general use as the comment above the macro definition clearly says: * Check whether we were atomic before we did preempt_disable(): * (used by the scheduler, *after* releasing the kernel lock) On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by accident, but with CONFIG_PREEMPT=y it's just broken. The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210 [akpm@linux-foundation.org: fix build] Signed-off-by: Thomas Gleixner Cc: Len Brown Cc: Francois Valenduc Cc: Lin Ming Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

irq: Add new IRQ flag IRQF_NO_SUSPEND

2010-08-13T20:31:07Z

commit 685fd0b4ea3f0f1d5385610b0d5b57775a8d5842 upstream. A small number of users of IRQF_TIMER are using it for the implied no suspend behaviour on interrupts which are not timer interrupts. Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to __IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags. Signed-off-by: Ian Campbell Cc: Jeremy Fitzhardinge Cc: Dmitry Torokhov Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Grant Likely Cc: xen-devel@lists.xensource.com Cc: linux-input@vger.kernel.org Cc: linuxppc-dev@ozlabs.org Cc: devicetree-discuss@lists.ozlabs.org LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

net: Fix NETDEV_NOTIFY_PEERS to not conflict with NETDEV_BONDING_DESLAVE.

2010-08-13T20:31:06Z

commit 38117d1495e587fbb10d6e55733139a27893cef5 upstream. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

l2tp: fix export of header file for userspace

2010-08-13T20:31:05Z

commit 4565956dc0847985c0403c9ebbf274b6a122e1e2 upstream. The header file l2tp.h should be exported to the installed include/linux/ tree for userspace programs. This patch fixes compilation errors in L2TP userspace apps which want to use the new L2TP support introduced in 2.6.35. Signed-off-by: James Chapman Signed-off-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman