linux, branch v2.6.35.11

Release 2.6.35.11

2011-02-06T19:04:07Z

Release 2.6.35.11 Signed-off-by: Andi Kleen

mac80211: fix initialization of skb->cb in ieee80211_subif_start_xmit

2011-02-06T19:04:07Z

[ upstream commit 489ee9195a7de9e6bc833d639ff6b553ffdad90e ] The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs' added a check for copying the skb if it's shared, however the tx info variable still points at the cb of the old skb Signed-off-by: Felix Fietkau Acked-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

mac80211: fix mesh forwarding when ratelimited too

2011-02-06T19:04:07Z

[ upstream commit 919bbad580445801c22ef6ccbe624551fee652bd ] Commit b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 said: Under memory pressure, the mac80211 mesh code may helpfully print a message that it failed to clone a mesh frame and then will proceed to crash trying to use it anyway. Fix that. Avoid the reference whenever the frame copy is unsuccessful regardless of the debug message being suppressed or printed. Cc: stable@kernel.org [2.6.27+] Signed-off-by: Milton Miller Signed-off-by: John W. Linville Signed-off-by: Andi Kleen

revert-drm-radeon-kms-properly-compute-group_size-on-6xx-7xx

2011-02-06T19:04:06Z

Revert drm/radeon/kms: properly compute group_size on 6xx/7xx From: Steve Conklin We discovered a regression for Radeon users in our latest proposed kernel for 2.6.35 (Maverick), and have isolated it to this patch: http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.35.y.git;a=commit;h=b8e9a4a45f8427837f4dba89 +bda4d4e3f3a5c726 We took that patch as part of 2.6.35.10, and one of our testers has reported that our build of that kernel also exhibits the problem. These are mainline kernels built with the Ubuntu configs. http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35.10-maverick/ Our bug report is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703553 Upstream bug report: https://bugzilla.kernel.org/show_bug.cgi?id=24802 Signed-off-by: Andi Kleen

Input: i8042 - introduce 'notimeout' blacklist for Dell Vostro V13

2011-02-06T19:03:53Z

i8042 controller present in Dell Vostro V13 errorneously signals spurious timeouts. Introduce i8042.notimeout parameter for ignoring i8042-signalled timeouts and apply this quirk automatically for Dell Vostro V13, based on DMI match. In addition to that, this machine also needs to be added to nomux blacklist. Signed-off-by: Jiri Kosina Signed-off-by: Dmitry Torokhov Signed-off-by: Andi Kleen

mac80211: fix hard lockup in sta_addba_resp_timer_expired

2011-02-06T19:03:53Z

Problem is 2.6.35 specific, bug was introduced in backport of upstream 44271488b91c9eecf249e075a1805dd887e222d2 commit. We can not call del_timer_sync(addba_resp_timer) from ___ieee80211_stop_tx_ba_session(), as this function can be called from that timer callback. To fix, simply use not synchronous del_timer(). Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459 Reported-and-tested-by: Mathieu Chouquet-Stringer Signed-off-by: Stanislaw Gruszka Signed-off-by: Andi Kleen

gspca - sonixj: Add a flag in the driver_info table

2011-02-06T19:03:53Z

commit c6c14330717f9850b4b4c054b81424b9979cd07d upstream. Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

gspca - sonixj: Set the flag for some devices

2011-02-06T19:03:52Z

commit b2272a49e7df37732d73988f00468ce31e1ebc92 upstream. The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same value as other webcams with the same sensor. For now, only two webcams have been so detected: the Microsoft's VX1000 and VX3000. Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

posix-cpu-timers: workaround to suppress the problems with mt exec

2011-02-06T19:03:52Z

commit e0a70217107e6f9844628120412cb27bb4cea194 upstream. posix-cpu-timers.c correctly assumes that the dying process does posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD timers from signal->cpu_timers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after de_thread() changes the leader. After that almost every posix_cpu_timer_ method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of task_struct. Also, the locking should be reworked completely. In particular, tasklist_lock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change __exit_signal() to do posix_cpu_timers_exit_group() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between de_thread() and release_task() is small, we can pretend that sys_timer_create() was called before de_thread(). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree()

2011-02-06T19:03:52Z

commit 5cdd2de0a76d0ac47f107c8a7b32d75d25768dc1 upstream. In arch/x86/kernel/microcode_intel.c::generic_load_microcode() we have this: while (leftover) { ... if (get_ucode_data(mc, ucode_ptr, mc_size) || microcode_sanity_check(mc) < 0) { vfree(mc); break; } ... } if (mc) vfree(mc); This will cause a double free of 'mc'. This patch fixes that by just removing the vfree() call in the loop since 'mc' will be freed nicely just after we break out of the loop. There's also a second change in the patch. I noticed a lot of checks for pointers being NULL before passing them to vfree(). That's completely redundant since vfree() deals gracefully with being passed a NULL pointer. Removing the redundant checks yields a nice size decrease for the object file. Size before the patch: text data bss dec hex filename 4578 240 1032 5850 16da arch/x86/kernel/microcode_intel.o Size after the patch: text data bss dec hex filename 4489 240 984 5713 1651 arch/x86/kernel/microcode_intel.o Signed-off-by: Jesper Juhl Acked-by: Tigran Aivazian Signed-off-by: Andi Kleen Cc: Shaohua Li LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman