commit d3c80676325f3475ff8f0db079aa0a9cb6131a07
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Mon Nov 7 12:58:56 2011 -0800

    Linux 2.6.32.47

commit fbba687e2a46ae22591cf3b0a544ee96c2a6e1b5
Author: Artur Zimmer <artur128@3dzimmer.de>
Date:   Wed Aug 10 03:51:28 2011 +0200

    USB: Serial: Add PID(0xF7C0) to FTDI SIO driver for a zeitcontrol-device
    
    commit ce7e9065958191e6b7ca49d7ed0e1099c486d198 upstream.
    
    Here is a patch for a new PID (zeitcontrol-device mifare-reader FT232BL(like FT232BM but lead free)).
    
    Signed-off-by: Artur Zimmer <artur128@3dzimmer.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 75fca7083c97c3b500c76e49d75bd7ae911c29da
Author: Florian Echtler <floe@butterbrot.org>
Date:   Tue Aug 9 13:37:49 2011 +0200

    USB: Serial: Add device ID for Sierra Wireless MC8305
    
    commit 2f1def2695c223b2aa325e5e47d0d64200a45d23 upstream.
    
    A new device ID pair is added for Sierra Wireless MC8305.
    
    Signed-off-by: Florian Echtler <floe@butterbrot.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 12aba73936ab53cf0536b48b1403ed98f016fa6f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Aug 31 11:54:51 2011 -0400

    ext2,ext3,ext4: don't inherit APPEND_FL or IMMUTABLE_FL for new inodes
    
    commit 1cd9f0976aa4606db8d6e3dc3edd0aca8019372a upstream.
    
    This doesn't make much sense, and it exposes a bug in the kernel where
    attempts to create a new file in an append-only directory using
    O_CREAT will fail (but still leave a zero-length file).  This was
    discovered when xfstests #79 was generalized so it could run on all
    file systems.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c13c9019050685a1234d85fd0f45909168512f24
Author: Alexandre Bounine <alexandre.bounine@idt.com>
Date:   Wed Nov 2 13:39:15 2011 -0700

    drivers/net/rionet.c: fix ethernet address macros for LE platforms
    
    commit e0c87bd95e8dad455c23bc56513af8dcb1737e55 upstream.
    
    Modify Ethernet addess macros to be compatible with BE/LE platforms
    
    Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
    Cc: Chul Kim <chul.kim@idt.com>
    Cc: Kumar Gala <galak@kernel.crashing.org>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Cc: Li Yang <leoli@freescale.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 177353670085c14e1d358db8bf812bd72a9268c7
Author: Zheng Liu <wenqing.lz@taobao.com>
Date:   Fri Oct 28 20:34:02 2011 +0800

    ext4: fix BUG_ON() in ext4_ext_insert_extent()
    
    Does not corrispond with a direct commit in Linus's tree as it was fixed
    differently in the 3.0 release.
    
    
    We will meet with a BUG_ON() if following script is run.
    
    mkfs.ext4 -b 4096 /dev/sdb1 1000000
    mount -t ext4 /dev/sdb1 /mnt/sdb1
    fallocate -l 100M /mnt/sdb1/test
    sync
    for((i=0;i<170;i++))
    do
            dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1
    seek=`expr $i \* 2`
    done
    umount /mnt/sdb1
    mount -t ext4 /dev/sdb1 /mnt/sdb1
    dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=341
    umount /mnt/sdb1
    mount /dev/sdb1 /mnt/sdb1
    dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=340
    sync
    
    The reason is that it forgot to mark dirty when splitting two extents in
    ext4_ext_convert_to_initialized(). Althrough ex has been updated in
    memory, it is not dirtied both in ext4_ext_convert_to_initialized() and
    ext4_ext_insert_extent(). The disk layout is corrupted. Then it will
    meet with a BUG_ON() when writting at the start of that extent again.
    
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Xiaoyun Mao <xiaoyun.maoxy@aliyun-inc.com>
    Cc: Yingbin Wang <yingbin.wangyb@aliyun-inc.com>
    Cc: Jia Wan <jia.wanj@aliyun-inc.com>
    Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit bfd62064efe736c254679f66ee37cf087ad60a72
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Sat May 22 20:37:44 2010 +0000

    net_sched: Fix qdisc_notify()
    
    commit 53b0f08042f04813cd1a7473dacd3edfacb28eb3 upstream.
    
    Ben Pfaff reported a kernel oops and provided a test program to
    reproduce it.
    
    https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805
    
    tc_fill_qdisc() should not be called for builtin qdisc, or it
    dereference a NULL pointer to get device ifindex.
    
    Fix is to always use tc_qdisc_dump_ignore() before calling
    tc_fill_qdisc().
    
    Reported-by: Ben Pfaff <blp@nicira.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 5cabd386ccf73b4a267f8c95e3a0b6e88f297188
Author: Luciano Coelho <coelho@ti.com>
Date:   Tue Jun 7 20:42:26 2011 +0300

    nl80211: fix overflow in ssid_len
    
    commit 57a27e1d6a3bb9ad4efeebd3a8c71156d6207536 upstream.
    
    When one of the SSID's length passed in a scan or sched_scan request
    is larger than 255, there will be an overflow in the u8 that is used
    to store the length before checking.  This causes the check to fail
    and we overrun the buffer when copying the SSID.
    
    Fix this by checking the nl80211 attribute length before copying it to
    the struct.
    
    This is a follow up for the previous commit
    208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem
    entirely.
    
    Reported-by: Ido Yariv <ido@wizery.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9bb38ae0b3a03b774dd026bf1c7758d2d107f464
Author: Dan Rosenberg <drosenberg@vsecurity.com>
Date:   Fri Jun 24 08:38:05 2011 -0400

    Bluetooth: Prevent buffer overflow in l2cap config request
    
    commit 7ac28817536797fd40e9646452183606f9e17f71 upstream.
    
    A remote user can provide a small value for the command size field in
    the command header of an l2cap configuration request, resulting in an
    integer underflow when subtracting the size of the configuration request
    header.  This results in copying a very large amount of data via
    memcpy() and destroying the kernel heap.  Check for underflow.
    
    Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
    Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dbb6e675314ddf4f1011a080e2fee0012134f83f
Author: Hugh Dickins <hughd@google.com>
Date:   Mon May 9 17:44:42 2011 -0700

    vm: fix vm_pgoff wrap in upward expansion
    
    commit 42c36f63ac1366ab0ecc2d5717821362c259f517 upstream.
    
    Commit a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed
    the case of an expanding mapping causing vm_pgoff wrapping when you had
    downward stack expansion.  But there was another case where IA64 and
    PA-RISC expand mappings: upward expansion.
    
    This fixes that case too.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c1bf02fadd5bbd27c6ba3a8de4c8cdc0e36231e7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Apr 13 08:07:28 2011 -0700

    vm: fix vm_pgoff wrap in stack expansion
    
    commit a626ca6a656450e9f4df91d0dda238fff23285f4 upstream.
    
    Commit 982134ba6261 ("mm: avoid wrapping vm_pgoff in mremap()") fixed
    the case of a expanding mapping causing vm_pgoff wrapping when you used
    mremap.  But there was another case where we expand mappings hiding in
    plain sight: the automatic stack expansion.
    
    This fixes that case too.
    
    This one also found by Robert Święcki, using his nasty system call
    fuzzer tool.  Good job.
    
    Reported-and-tested-by: Robert Święcki <robert@swiecki.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d77e3459f7edf03567024ad9442dace4bcb81b9c
Author: Filip Palian <s3810@pjwstk.edu.pl>
Date:   Thu May 12 19:32:46 2011 +0200

    Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.
    
    commit 8d03e971cf403305217b8e62db3a2e5ad2d6263f upstream.
    
    Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
    byte each. This byte in "cinfo" is copied to userspace uninitialized.
    
    Signed-off-by: Filip Palian <filip.palian@pjwstk.edu.pl>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 82ccf268c0fc98dfc282ff2e240656530618d49e
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue May 31 15:15:34 2011 -0400

    NLM: Don't hang forever on NLM unlock requests
    
    commit 0b760113a3a155269a3fba93a409c640031dd68f upstream.
    
    If the NLM daemon is killed on the NFS server, we can currently end up
    hanging forever on an 'unlock' request, instead of aborting. Basically,
    if the rpcbind request fails, or the server keeps returning garbage, we
    really want to quit instead of retrying.
    
    Tested-by: Vasily Averin <vvs@sw.ru>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cdb19fb1cc7c1854d5698e43139f7920bcab274a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Mar 23 15:52:50 2011 -0400

    deal with races in /proc/*/{syscall,stack,personality}
    
    commit a9712bc12c40c172e393f85a9b2ba8db4bf59509 upstream.
    
    All of those are rw-r--r-- and all are broken for suid - if you open
    a file before the target does suid-root exec, you'll be still able
    to access it.  For personality it's not a big deal, but for syscall
    and stack it's a real problem.
    
    Fix: check that task is tracable for you at the time of read().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6719bac67645ca27b2e74726387705b589a89a24
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Tue Nov 23 14:09:15 2010 +0000

    scm: lower SCM_MAX_FD
    
    commit bba14de98753cb6599a2dae0e520714b2153522d upstream.
    
    Lower SCM_MAX_FD from 255 to 253 so that allocations for scm_fp_list are
    halved. (commit f8d570a4 added two pointers in this structure)
    
    scm_fp_dup() should not copy whole structure (and trigger kmemcheck
    warnings), but only the used part. While we are at it, only allocate
    needed size.
    
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2bc360b3483676fd47f7cd377d9464707bd80902
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Thu Oct 20 20:50:25 2011 +0200

    thinkpad-acpi: module autoloading for newer Lenovo ThinkPads.
    
    commit 9fbdaeb4f4dd14a0caa9fc35c496d5440c251a3a upstream.
    
    The newer Lenovo ThinkPads have HKEY HID of LEN0068 instead
    of IBM0068. Added new HID so that thinkpad_acpi module will
    auto load on these newer Lenovo ThinkPads.
    
    Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: stable@vger.kernel.org
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Andy Lutomirski <luto@mit.edu>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6efcfa8880fb9ca080c7c50feb71dd0bf04ed108
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Mar 23 13:35:42 2010 -0700

    kcore: fix test for end of list
    
    commit 4fd2c20d964a8fb9861045f1022475c9d200d684 upstream.
    
    "m" is never NULL here.  We need a different test for the end of list
    condition.
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Leonardo Chiquitto <leonardo.lists@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 35b6863ce555ce59e36a2c2bf7c8a8e9a9da577b
Author: Florian Fainelli <florian@openwrt.org>
Date:   Mon Oct 17 19:47:44 2011 +0200

    watchdog: mtx1-wdt: fix build failure
    
    Commit 6d86a0ee (watchdog: mtx1-wdt: request gpio before using it) was
    backported from upstream. The patch is using a gpiolib call which is only
    available in kernel 2.6.34+. Fix build by using the "old" gpiolib API
    instead.
    
    Signed-off-by: Florian Fainelli <florian@openwrt.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0804bd48bb9787acf5ae7d2f155fdea11d198018
Author: Florian Fainelli <florian@openwrt.org>
Date:   Mon Oct 17 19:43:06 2011 +0200

    Revert "MIPS: MTX-1: Make au1000_eth probe all PHY
    
    Commit ec3eb823 was not applicable in 2.6.32 and introduces a build breakage.
    Revert that commit since it is irrelevant for this kernel version.
    
    Acked-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Florian Fainelli <florian@openwrt.org>

commit abd2ed99e8e0cf1481e7133e90587128e79fd689
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Wed Nov 2 14:04:11 2011 -0700

    Revert "usb: musb: restore INDEX register in resume path"
    
    This reverts commit 262e2d9d559334e09bc80516132ea99d82f97b8c.
    
    Turns out this breaks the build, and as such, really isn't needed for
    the 2.6.32-stable branch at all.
    
    Reported-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Cc: Anand Gadiyar <gadiyar@ti.com>
    Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0f12a6ad9fa3a03f2bcee36c9cb704821e244c40
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Mon Oct 3 15:37:00 2011 +0100

    genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
    
    commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream
    
    This adds a mechanism to resume selected IRQs during syscore_resume
    instead of dpm_resume_noirq.
    
    Under Xen we need to resume IRQs associated with IPIs early enough
    that the resched IPI is unmasked and we can therefore schedule
    ourselves out of the stop_machine where the suspend/resume takes
    place.
    
    This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".
    
    Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
    resume function directly from sysdev_resume).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
    Cc: xen-devel <xen-devel@lists.xensource.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f8723d9144b7bc47a8ab994bad990508c1ab848c
Author: Philipp Hahn <hahn@univention.de>
Date:   Mon Sep 12 12:52:51 2011 -0300

    KVM: x86: Reset tsc_timestamp on TSC writes
    
    There is no upstream commit ID for this patch since it is not a straight
    backport from upstream. It is a fix only relevant to 2.6.32.y.
    
    Since 1d5f066e0b63271b67eac6d3752f8aa96adcbddb from 2.6.37 was
    back-ported to 2.6.32.40 as ad2088cabe0fd7f633f38ba106025d33ed9a2105,
    the following patch is needed to add the needed reset logic to 2.6.32 as
    well.
    
    
    Bug #23257: Reset tsc_timestamp on TSC writes
    
    vcpu->last_guest_tsc is updated in vcpu_enter_guest() and kvm_arch_vcpu_put()
    by getting the last value of the TSC from the guest.
    On reset, the SeaBIOS resets the TSC to 0, which triggers a bug on the next
    call to kvm_write_guest_time(): Since vcpu->hw_clock.tsc_timestamp still
    contains the old value before the reset, "max_kernel_ns = vcpu->last_guest_tsc
    - vcpu->hw_clock.tsc_timestamp" gets negative. Since the variable is u64, it
     gets translated to a large positive value.
    
    [9333.197080]
    vcpu->last_guest_tsc        =209_328_760_015           ←
    vcpu->hv_clock.tsc_timestamp=209_328_708_109
    vcpu->last_kernel_ns        =9_333_179_830_643
    kernel_ns                   =9_333_197_073_429
    max_kernel_ns               =9_333_179_847_943         ←
    
    [9336.910995]
    vcpu->last_guest_tsc        =9_438_510_584             ←
    vcpu->hv_clock.tsc_timestamp=211_080_593_143
    vcpu->last_kernel_ns        =9_333_763_732_907
    kernel_ns                   =9_336_910_990_771
    max_kernel_ns               =6_148_296_831_006_663_830 ←
    
    For completeness, here are the values for my 3 GHz CPU:
    vcpu->hv_clock.tsc_shift         =-1
    vcpu->hv_clock.tsc_to_system_mul =2_863_019_502
    
    This makes the guest kernel crawl very slowly when clocksource=kvmclock is
    used: sleeps take way longer than expected and don't match wall clock any more.
    The times printed with printk() don't match real time and the reboot often
    stalls for long times.
    
    In linux-git this isn't a problem, since on every MSR_IA32_TSC write
    vcpu->arch.hv_clock.tsc_timestamp is reset to 0, which disables above logic.
    The code there is only in arch/x86/kvm/x86.c, since much of the kvm-clock
    related code has been refactured for 2.6.37:
    	99e3e30a arch/x86/kvm/x86.c
            (Zachary Amsden            2010-08-19 22:07:17 -1000 1084)
            vcpu->arch.hv_clock.tsc_timestamp = 0;
    
    Signed-off-by: Philipp Hahn <hahn@univention.de>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e4ce2d7e6b2f75d5a8a82b326d153b6fe9d3ac06
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Tue Feb 8 14:03:31 2011 +0000

    xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
    
    commit f611f2da99420abc973c32cdbddbf5c365d0a20c upstream.
    
    The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via
    IRQF_TIMER. The following patch fixes the issue.
    
    With this fixlet PV guest migration works just fine. I also booted the
    entire series as a dom0 kernel and it appeared fine.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b689cc1e09a7394121eed6b5e700d0202bcf9808
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Thu Sep 29 15:28:26 2011 +0530

    cfq: Don't allow queue merges for queues that have no process references
    
    commit c10b61f0910466b4b99c266a7d76ac4390743fb5 upstream.
    
    Hi,
    
    A user reported a kernel bug when running a particular program that did
    the following:
    
    created 32 threads
    - each thread took a mutex, grabbed a global offset, added a buffer size
      to that offset, released the lock
    - read from the given offset in the file
    - created a new thread to do the same
    - exited
    
    The result is that cfq's close cooperator logic would trigger, as the
    threads were issuing I/O within the mean seek distance of one another.
    This workload managed to routinely trigger a use after free bug when
    walking the list of merge candidates for a particular cfqq
    (cfqq->new_cfqq).  The logic used for merging queues looks like this:
    
    static void cfq_setup_merge(struct cfq_queue *cfqq, struct cfq_queue *new_cfqq)
    {
    	int process_refs, new_process_refs;
    	struct cfq_queue *__cfqq;
    
    	/* Avoid a circular list and skip interim queue merges */
    	while ((__cfqq = new_cfqq->new_cfqq)) {
    		if (__cfqq == cfqq)
    			return;
    		new_cfqq = __cfqq;
    	}
    
    	process_refs = cfqq_process_refs(cfqq);
    	/*
    	 * If the process for the cfqq has gone away, there is no
    	 * sense in merging the queues.
    	 */
    	if (process_refs == 0)
    		return;
    
    	/*
    	 * Merge in the direction of the lesser amount of work.
    	 */
    	new_process_refs = cfqq_process_refs(new_cfqq);
    	if (new_process_refs >= process_refs) {
    		cfqq->new_cfqq = new_cfqq;
    		atomic_add(process_refs, &new_cfqq->ref);
    	} else {
    		new_cfqq->new_cfqq = cfqq;
    		atomic_add(new_process_refs, &cfqq->ref);
    	}
    }
    
    When a merge candidate is found, we add the process references for the
    queue with less references to the queue with more.  The actual merging
    of queues happens when a new request is issued for a given cfqq.  In the
    case of the test program, it only does a single pread call to read in
    1MB, so the actual merge never happens.
    
    Normally, this is fine, as when the queue exits, we simply drop the
    references we took on the other cfqqs in the merge chain:
    
    	/*
    	 * If this queue was scheduled to merge with another queue, be
    	 * sure to drop the reference taken on that queue (and others in
    	 * the merge chain).  See cfq_setup_merge and cfq_merge_cfqqs.
    	 */
    	__cfqq = cfqq->new_cfqq;
    	while (__cfqq) {
    		if (__cfqq == cfqq) {
    			WARN(1, "cfqq->new_cfqq loop detected\n");
    			break;
    		}
    		next = __cfqq->new_cfqq;
    		cfq_put_queue(__cfqq);
    		__cfqq = next;
    	}
    
    However, there is a hole in this logic.  Consider the following (and
    keep in mind that each I/O keeps a reference to the cfqq):
    
    q1->new_cfqq = q2   // q2 now has 2 process references
    q3->new_cfqq = q2   // q2 now has 3 process references
    
    // the process associated with q2 exits
    // q2 now has 2 process references
    
    // queue 1 exits, drops its reference on q2
    // q2 now has 1 process reference
    
    // q3 exits, so has 0 process references, and hence drops its references
    // to q2, which leaves q2 also with 0 process references
    
    q4 comes along and wants to merge with q3
    
    q3->new_cfqq still points at q2!  We follow that link and end up at an
    already freed cfqq.
    
    So, the fix is to not follow a merge chain if the top-most queue does
    not have a process reference, otherwise any queue in the chain could be
    already freed.  I also changed the logic to disallow merging with a
    queue that does not have any process references.  Previously, we did
    this check for one of the merge candidates, but not the other.  That
    doesn't really make sense.
    
    Without the attached patch, my system would BUG within a couple of
    seconds of running the reproducer program.  With the patch applied, my
    system ran the program for over an hour without issues.
    
    This addresses the following bugzilla:
        https://bugzilla.kernel.org/show_bug.cgi?id=16217
    
    Thanks a ton to Phil Carns for providing the bug report and an excellent
    reproducer.
    
    [ Note for stable: this applies to 2.6.32/33/34 ].
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Reported-by: Phil Carns <carns@mcs.anl.gov>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f17984a975b6aa4c47a173d93c45eb57ca5b125e
Author: Jens Axboe <jens.axboe@oracle.com>
Date:   Thu Sep 29 15:27:56 2011 +0530

    cfq-iosched: get rid of the coop_preempt flag
    
    commit e00ef7997195e4f8e10593727a6286e2e2802159 upstream
    
    We need to rework this logic post the cooperating cfq_queue merging,
    for now just get rid of it and Jeff Moyer will fix the fall out.
    
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 63d34056ad814679badc9182292c172af242d565
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Thu Sep 29 15:27:45 2011 +0530

    cfq: break apart merged cfqqs if they stop cooperating
    
    commit e6c5bc737ab71e4af6025ef7d150f5a26ae5f146 upstream.
    
    cfq_queues are merged if they are issuing requests within the mean seek
    distance of one another.  This patch detects when the coopearting stops and
    breaks the queues back up.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6bfa77d42c6f0772bf46389e749bb0ff69e00448
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Thu Sep 29 15:27:37 2011 +0530

    cfq: change the meaning of the cfqq_coop flag
    
    commit b3b6d0408c953524f979468562e7e210d8634150 upstream
    
    The flag used to indicate that a cfqq was allowed to jump ahead in the
    scheduling order due to submitting a request close to the queue that
    just executed.  Since closely cooperating queues are now merged, the flag
    holds little meaning.  Change it to indicate that multiple queues were
    merged.  This will later be used to allow the breaking up of merged queues
    when they are no longer cooperating.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d34507d090ff70f0663659e70b5980248a5d6774
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Thu Sep 29 15:27:11 2011 +0530

    cfq: merge cooperating cfq_queues
    
    commit df5fe3e8e13883f58dc97489076bbcc150789a21 upstream.
    
    When cooperating cfq_queues are detected currently, they are allowed to
    skip ahead in the scheduling order.  It is much more efficient to
    automatically share the cfq_queue data structure between cooperating processes.
    Performance of the read-test2 benchmark (which is written to emulate the
    dump(8) utility) went from 12MB/s to 90MB/s on my SATA disk.  NFS servers
    with multiple nfsd threads also saw performance increases.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4a78a06ce2ecea224c55eb2e171ea020110ecaa9
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Thu Sep 29 15:26:58 2011 +0530

    cfq: calculate the seek_mean per cfq_queue not per cfq_io_context
    
    commit b2c18e1e08a5a9663094d57bb4be2f02226ee61c upstream.
    
    async cfq_queue's are already shared between processes within the same
    priority, and forthcoming patches will change the mapping of cic to sync
    cfq_queue from 1:1 to 1:N.  So, calculate the seekiness of a process
    based on the cfq_queue instead of the cfq_io_context.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 610fba92198e257bb039e49c391bb73cd0c1b2b1
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Nov 2 13:17:27 2011 +0100

    um: fix ubd cow size
    
    commit 8535639810e578960233ad39def3ac2157b0c3ec upstream.
    
    ubd_file_size() cannot use ubd_dev->cow.file because at this time
    ubd_dev->cow.file is not initialized.
    Therefore, ubd_file_size() will always report a wrong disk size when
    COW files are used.
    Reading from /dev/ubd* would crash the kernel.
    
    We have to read the correct disk size from the COW file's backing
    file.
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6ae639c55f24aebe2b395b4fefb75064a59d6e3b
Author: Paul Fertser <fercerpav@gmail.com>
Date:   Mon Oct 10 11:19:23 2011 +0400

    plat-mxc: iomux-v3.h: implicitly enable pull-up/down when that's desired
    
    commit 6571534b600b8ca1936ff5630b9e0947f21faf16 upstream.
    
    To configure pads during the initialisation a set of special constants
    is used, e.g.
    #define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP)
    
    The problem is that no pull-up/down is getting activated unless both
    PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module
    enable) set. This is clearly stated in the i.MX25 datasheet and is
    confirmed by the measurements on hardware. This leads to some rather
    hard to understand bugs such as misdetecting an absent ethernet PHY (a
    real bug i had), unstable data transfer etc. This might affect mx25,
    mx35, mx50, mx51 and mx53 SoCs.
    
    It's reasonable to expect that if the pullup value is specified, the
    intention was to have it actually active, so we implicitly add the
    needed bits.
    
    Signed-off-by: Paul Fertser <fercerpav@gmail.com>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b8237b3f1dac67a3e10bc0f151e84de81ad688bd
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Thu Jul 28 16:38:54 2011 -0300

    tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
    
    commit 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e upstream.
    
    This device is not using the proper demod IF. Instead of using the
    IF macro, it is specifying a IF frequency. This doesn't work, as xc3028
    needs to load an specific SCODE for the tuner. In this case, there's
    no IF table for 5 MHz.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cd7d323474d891b72034f981c22d282805a63a3e
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Sat Jul 16 00:51:00 2011 -0300

    uvcvideo: Set alternate setting 0 on resume if the bus has been reset
    
    commit d59a7b1dbce8b972ec2dc9fcaaae0bfa23687423 upstream.
    
    If the bus has been reset on resume, set the alternate setting to 0.
    This should be the default value, but some devices crash or otherwise
    misbehave if they don't receive a SET_INTERFACE request before any other
    video control request.
    
    Microdia's 0c45:6437 camera has been found to require this change or it
    will stop sending video data after resume.
    
    uvc_video.c]
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2955ef81efd268149787d93043c912f509150efa
Author: Jean Delvare <jdelvare@suse.de>
Date:   Fri Jul 8 11:04:38 2011 +0200

    carminefb: Fix module parameters permissions
    
    commit c84c14224bbca6ec60d5851fcc87be0e34df2f44 upstream.
    
    The third parameter of module_param is supposed to be an octal value.
    The missing leading "0" causes the following:
    
    $ ls -l /sys/module/carminefb/parameters/
    total 0
    -rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_displays
    -rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode
    -rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode_str
    
    After fixing the perm parameter, we get the expected:
    
    $ ls -l /sys/module/carminefb/parameters/
    total 0
    -r--r--r-- 1 root root 4096 Jul  8 08:56 fb_displays
    -r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode
    -r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode_str
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Signed-off-by: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e64b7bab4ff4db9caa98fd139126cde8edfa029e
Author: Joerg Roedel <joerg.roedel@amd.com>
Date:   Tue Oct 11 17:41:32 2011 +0200

    iommu/amd: Fix wrong shift direction
    
    commit fcd0861db1cf4e6ed99f60a815b7b72c2ed36ea4 upstream.
    
    The shift direction was wrong because the function takes a
    page number and i is the address is the loop.
    
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a297437cf7eb9938a442cc9601af74237e276e0c
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Sun Oct 30 15:16:52 2011 +0100

    ccwgroup: move attributes to attribute group
    
    commit dbdf1afcaaabe83dea15a3cb9b9013e73ae3b1ad upstream.
    
    Put sysfs attributes of ccwgroup devices in an attribute group to
    ensure that these attributes are actually present when userspace
    is notified via uevents.
    
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4796d51e7cedb82b44e9e2375b48ef846de47b08
Author: Carsten Otte <cotte@de.ibm.com>
Date:   Tue Oct 18 12:27:12 2011 +0200

    KVM: s390: check cpu_id prior to using it
    
    commit 4d47555a80495657161a7e71ec3014ff2021e450 upstream.
    
    We use the cpu id provided by userspace as array index here. Thus we
    clearly need to check it first. Ooops.
    
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 293009933e4936c638a65935d5cc02c3d21e2401
Author: Axel Lin <axel.lin@gmail.com>
Date:   Thu Oct 13 17:17:06 2011 +0800

    ASoC: ak4535: fixup cache register table
    
    commit 7c04241acbdaf97f1448dcccd27ea0fcd1a57684 upstream.
    
    ak4535_reg should be 8bit, but cache table is defined as 16bit.
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 145857fa9ebd3bc7f85e8cfc70892120383df823
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Oct 13 02:03:54 2011 -0700

    ASoC: ak4642: fixup cache register table
    
    commit 19b115e523208a926813751aac8934cf3fc6085e upstream.
    
    ak4642 register was 8bit, but cache table was defined as 16bit.
    ak4642 doesn't work correctry without this patch.
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d85b1ce7fd0ecfdd43e8c3e67eb953900c209939
Author: Axel Lin <axel.lin@gmail.com>
Date:   Wed Oct 26 09:53:41 2011 +0800

    ASoC: wm8940: Properly set codec->dapm.bias_level
    
    commit 5927f94700e860ae27ff24e7f3bc9e4f7b9922eb upstream.
    
    Reported-by: Chris Paulson-Ellis <chris@edesix.com>
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 92508d600d3b89cf7165a017c2b67e2c3cdca098
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Oct 10 17:34:31 2011 -0400

    nfsd4: ignore WANT bits in open downgrade
    
    commit c30e92df30d7d5fe65262fbce5d1b7de675fe34e upstream.
    
    We don't use WANT bits yet--and sending them can probably trigger a
    BUG() further down.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 549115ad71a20ae4d3d87a402e1644b710e6d010
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Mon Aug 8 17:38:08 2011 +0200

    nfsd4: Remove check for a 32-bit cookie in nfsd4_readdir()
    
    commit 832023bffb4b493f230be901f681020caf3ed1f8 upstream.
    
    Fan Yong <yong.fan@whamcloud.com> noticed setting
    FMODE_32bithash wouldn't work with nfsd v4, as
    nfsd4_readdir() checks for 32 bit cookies. However, according to RFC 3530
    cookies have a 64 bit type and cookies are also defined as u64 in
    'struct nfsd4_readdir'. So remove the test for >32-bit values.
    
    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ec9ee3fc9e547d98eb66c260b84525f0a4e46df9
Author: hank <pyu@redhat.com>
Date:   Tue Sep 20 13:53:39 2011 -0700

    time: Change jiffies_to_clock_t() argument type to unsigned long
    
    commit cbbc719fccdb8cbd87350a05c0d33167c9b79365 upstream.
    
    The parameter's origin type is long. On an i386 architecture, it can
    easily be larger than 0x80000000, causing this function to convert it
    to a sign-extended u64 type.
    
    Change the type to unsigned long so we get the correct result.
    
    Signed-off-by: hank <pyu@redhat.com>
    Cc: John Stultz <john.stultz@linaro.org>
    [ build fix ]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4d3e486fb80b593cdb04d240b2cadaf8c40dd863
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Oct 26 13:10:39 2011 +1030

    kmod: prevent kmod_loop_msg overflow in __request_module()
    
    commit 37252db6aa576c34fd794a5a54fb32d7a8b3a07a upstream.
    
    Due to post-increment in condition of kmod_loop_msg in __request_module(),
    the system log can be spammed by much more than 5 instances of the 'runaway
    loop' message if the number of events triggering it makes the kmod_loop_msg
    to overflow.
    
    Fix that by making sure we never increment it past the threshold.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b628ea1f5cd046c9bd07c5ebef824bae08a85f1c
Author: Milan Broz <mbroz@redhat.com>
Date:   Mon Aug 22 15:51:34 2011 +0200

    kobj_uevent: Ignore if some listeners cannot handle message
    
    commit ebf4127cd677e9781b450e44dfaaa1cc595efcaa upstream.
    
    kobject_uevent() uses a multicast socket and should ignore
    if one of listeners cannot handle messages or nobody is
    listening at all.
    
    Easily reproducible when a process in system is cloned
    with CLONE_NEWNET flag.
    
    (See also http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5256)
    
    Signed-off-by: Milan Broz <mbroz@redhat.com>
    Acked-by: Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 87cab8620ac40a965d0676b42a081bda70f4cb96
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Mon Oct 17 21:16:39 2011 -0400

    Update email address for stable patch submission
    
    commit 5fa224295f0e0358c8bc0e5390702338df889def upstream.
    
    The stable@kernel.org email address has been replaced with the
    stable@vger.kernel.org mailing list.  Change the stable kernel rules to
    reference the new list instead of the semi-defunct email alias.
    
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dcf2e7c884e42a6ba946d604315fbd8a45478f78
Author: Jerry Huang <r66093@freescale.com>
Date:   Tue Oct 18 13:09:48 2011 +0800

    QE/FHCI: fixed the CONTROL bug
    
    commit 273d23574f9dacd9c63c80e7d63639a669aad441 upstream.
    
    For USB CONTROL transaction, when the data length is zero,
    the IN package is needed to finish this transaction in status stage.
    
    Signed-off-by: Jerry Huang <r66093@freescale.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 529c2034a4d0d8f6997915dc775e34e512cd35db
Author: Peter Stuge <peter@stuge.se>
Date:   Mon Oct 10 03:34:54 2011 +0200

    USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI Board
    
    commit 3687f641307eeff6f7fe31a88dc39db88e89238b upstream.
    
    Some Stellaris evaluation kits have the JTAG/SWD FTDI chip onboard,
    and some, like EK-LM3S9B90, come with a separate In-Circuit Debugger
    Interface Board. The ICDI board can also be used stand-alone, for
    other boards and chips than the kit it came with. The ICDI has both
    old style 20-pin JTAG connector and new style JTAG/SWD 10-pin 1.27mm
    pitch connector.
    
    Tested with EK-LM3S9B90, where the BD-ICDI board is included.
    
    Signed-off-by: Peter Stuge <peter@stuge.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3306c2d527b646109cf96ba1aea0748d5ef39b68
Author: Hakan Kvist <hakan.kvist@sonyericsson.com>
Date:   Mon Oct 3 13:41:15 2011 +0200

    USB: ftdi_sio: add PID for Sony Ericsson Urban
    
    commit 74bdf22b5c3858b06af46f19d05c23e76c40a3bb upstream.
    
    Add PID 0xfc8a, 0xfc8b for device Sony Ericsson Urban
    
    Signed-off-by: Hakan Kvist <hakan.kvist@sonyericsson.com>
    Signed-off-by: Oskar Andero <oskar.andero@sonyericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2eef924a8d4a459032ac0e7f268e87c815595fef
Author: Eric Benoit <eric@ecks.ca>
Date:   Sat Sep 24 02:04:50 2011 -0400

    USB: pl2303: add id for SMART device
    
    commit 598f0b703506da841d3459dc0c48506be14d1778 upstream.
    
    Add vendor and product ID for the SMART USB to serial adapter. These
    were meant to be used with their SMART Board whiteboards, but can be
    re-purposed for other tasks. Tested and working (at at least 9600 bps).
    
    Signed-off-by: Eric Benoit <eric@ecks.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8069ff2c2112b09f176d37576dd719d18daab794
Author: Oliver Neukum <oneukum@suse.de>
Date:   Tue Sep 13 08:42:21 2011 +0200

    USB: add RESET_RESUME for webcams shown to be quirky
    
    commit 2394d67e446bf616a0885167d5f0d397bdacfdfc upstream.
    
    The new runtime PM code has shown that many webcams suffer
    from a race condition that may crash them upon resume.
    Runtime PM is especially prone to show the problem because
    it retains power to the cameras at all times. However
    system suspension may also crash the devices and retain
    power to the devices.
    The only way to solve this problem without races is in
    usbcore with the RESET_RESUME quirk.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f37a43137b2ec8c551a8fd205e09cd50f20f3f87
Author: Denis Pershin <dyp@perchine.com>
Date:   Sun Sep 4 17:37:21 2011 +0700

    usb: cdc-acm: Owen SI-30 support
    
    commit 65e52f41fa944cef2e6d4222b8c54f46cc575214 upstream.
    
    here is the patch to support Owen SI-30 device.
    This is a pulse counter controller.
    http://www.owen.ru/en/catalog/93788515
    
    usb-drivers output:
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
    P:  Vendor=03eb ProdID=0030 Rev=01.01
    C:  #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=0mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
    
    This patch is installed on my home system which receives data from this
    controller connected to cold water counter.
    
    Signed-off-by: Denis Pershin <dyp@perchine.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6f32aa1bfe70f3493fdbf1fa425a17c795cc3c14
Author: Serge Hallyn <serge.hallyn@canonical.com>
Date:   Mon Sep 26 10:18:29 2011 -0500

    USB: pid_ns: ensure pid is not freed during kill_pid_info_as_uid
    
    commit aec01c5895051849ed842dc5b8794017a7751f28 upstream.
    
    Alan Stern points out that after spin_unlock(&ps->lock) there is no
    guarantee that ps->pid won't be freed.  Since kill_pid_info_as_uid() is
    called after the spin_unlock(), the pid passed to it must be pinned.
    
    Reported-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 01a9617ed2441ce3beb23f617ce7c58783a072be
Author: Luben Tuikov <ltuikov@yahoo.com>
Date:   Thu Nov 11 15:43:11 2010 -0800

    USB: storage: Use normalized sense when emulating autosense
    
    commit e16da02fcdf1c5e824432f88abf42623dafdf191 upstream.
    
    This patch solves two things:
    1) Enables autosense emulation code to correctly
    interpret descriptor format sense data, and
    2) Fixes a bug whereby the autosense emulation
    code would overwrite descriptor format sense data
    with SENSE KEY HARDWARE ERROR in fixed format, to
    incorrectly look like this:
    
    Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  Sense Key : Recovered Error [current] [descriptor]
    Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex):
    Oct 21 14:11:07 localhost kernel:        72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
    Oct 21 14:11:07 localhost kernel:        00 4f 00 c2 00 50
    Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  ASC=0x4 ASCQ=0x1d
    
    Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 584025553b65c1d4341f5da2971ad9baff9995cf
Author: Johannes Stezenbach <js@sig21.net>
Date:   Thu Sep 8 15:39:15 2011 +0200

    usbmon vs. tcpdump: fix dropped packet count
    
    commit 236c448cb6e7f82096101e1ace4b77f8b38f82c8 upstream.
    
    Report the number of dropped packets instead of zero
    when using the binary usbmon interface with tcpdump.
    
    # tcpdump -i usbmon1 -w dump
    tcpdump: listening on usbmon1, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes
    ^C2155 packets captured
    2155 packets received by filter
    1019 packets dropped by kernel
    
    Signed-off-by: Johannes Stezenbach <js@sig21.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f3127ac1a59d00140b9ed845c0ca787e92c8af27
Author: Nelson Elhage <nelhage@nelhage.com>
Date:   Mon Oct 31 17:13:14 2011 -0700

    epoll: fix spurious lockdep warnings
    
    commit d8805e633e054c816c47cb6e727c81f156d9253d upstream.
    
    epoll can acquire recursively acquire ep->mtx on multiple "struct
    eventpoll"s at once in the case where one epoll fd is monitoring another
    epoll fd.  This is perfectly OK, since we're careful about the lock
    ordering, but it causes spurious lockdep warnings.  Annotate the recursion
    using mutex_lock_nested, and add a comment explaining the nesting rules
    for good measure.
    
    Recent versions of systemd are triggering this, and it can also be
    demonstrated with the following trivial test program:
    
    --------------------8<--------------------
    
    int main(void) {
       int e1, e2;
       struct epoll_event evt = {
           .events = EPOLLIN
       };
    
       e1 = epoll_create1(0);
       e2 = epoll_create1(0);
       epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt);
       return 0;
    }
    --------------------8<--------------------
    
    Reported-by: Paul Bolle <pebolle@tiscali.nl>
    Tested-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Nelson Elhage <nelhage@nelhage.com>
    Acked-by: Jason Baron <jbaron@redhat.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 7064444e6ba8ae14fd4faa6fe24ec65a6b58f896
Author: Josh Stone <jistone@redhat.com>
Date:   Mon Oct 24 10:15:51 2011 -0700

    x86: Fix compilation bug in kprobes' twobyte_is_boostable
    
    commit 315eb8a2a1b7f335d40ceeeb11b9e067475eb881 upstream.
    
    When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
    noticed a warning about the asm operand for test_bit in kprobes'
    can_boost.  I discovered that this caused only the first long of
    twobyte_is_boostable[] to be output.
    
    Jakub filed and fixed gcc PR50571 to correct the warning and this output
    issue.  But to solve it for less current gcc, we can make kprobes'
    twobyte_is_boostable[] non-const, and it won't be optimized out.
    
    Before:
    
        CC      arch/x86/kernel/kprobes.o
      In file included from include/linux/bitops.h:22:0,
                       from include/linux/kernel.h:17,
                       from [...]/arch/x86/include/asm/percpu.h:44,
                       from [...]/arch/x86/include/asm/current.h:5,
                       from [...]/arch/x86/include/asm/processor.h:15,
                       from [...]/arch/x86/include/asm/atomic.h:6,
                       from include/linux/atomic.h:4,
                       from include/linux/mutex.h:18,
                       from include/linux/notifier.h:13,
                       from include/linux/kprobes.h:34,
                       from arch/x86/kernel/kprobes.c:43:
      [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
      [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
            without lvalue in asm operand 1 is deprecated [enabled by default]
    
      $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
           551:	0f a3 05 00 00 00 00 	bt     %eax,0x0
                              554: R_386_32	.rodata.cst4
    
      $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
    
      arch/x86/kernel/kprobes.o:     file format elf32-i386
    
      Contents of section .data:
       0000 48000000 00000000 00000000 00000000  H...............
      Contents of section .rodata.cst4:
       0000 4c030000                             L...
    
    Only a single long of twobyte_is_boostable[] is in the object file.
    
    After, without the const on twobyte_is_boostable:
    
      $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
           551:	0f a3 05 20 00 00 00 	bt     %eax,0x20
                              554: R_386_32	.data
    
      $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
    
      arch/x86/kernel/kprobes.o:     file format elf32-i386
    
      Contents of section .data:
       0000 48000000 00000000 00000000 00000000  H...............
       0010 00000000 00000000 00000000 00000000  ................
       0020 4c030000 0f000200 ffff0000 ffcff0c0  L...............
       0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77  ....;.......&..w
    
    Now all 32 bytes are output into .data instead.
    
    Signed-off-by: Josh Stone <jistone@redhat.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9a35d02273814b7355e43e3edc78b42dd7f842a6
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Tue Oct 18 14:07:51 2011 +0200

    ALSA: HDA: Add new revision for ALC662
    
    commit cc667a72d471e79fd8e5e291ea115923cf44dca0 upstream.
    
    The revision 0x100300 was found for ALC662. It seems to work well
    with patch_alc662.
    
    BugLink: http://bugs.launchpad.net/bugs/877373
    Tested-by: Shengyao Xue <Shengyao.xue@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Acked-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b60bd068b39970530cb65e9fbce115a30c0b0a06
Author: Jack Wang <jack_wang@usish.com>
Date:   Fri Sep 23 14:32:32 2011 +0800

    libsas: set sas_address and device type of rphy
    
    commit bb041a0e9c31229071b6e56e1d0d8374af0d2038 upstream.
    
    Libsas forget to set the sas_address and device type of rphy lead to file
    under /sys/class/sas_x show wrong value, fix that.
    
    Signed-off-by: Jack Wang <jack_wang@usish.com>
    Tested-by: Crystal Yu <crystal_yu@usish.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 7eef3c52dc365d19a05a974bd5fbc883feef1166
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Aug 1 19:43:45 2011 +1000

    ipr: Always initiate hard reset in kdump kernel
    
    commit 5d7c20b7fa5c6ca19e871b4050e321c99d32bd43 upstream.
    
    During kdump testing I noticed timeouts when initialising each IPR
    adapter. While the driver has logic to detect an adapter in an
    indeterminate state, it wasn't triggering and each adapter went
    through a 5 minute timeout before finally going operational.
    
    Some analysis showed the needs_hard_reset flag wasn't getting set.
    We can check the reset_devices kernel parameter which is set by
    kdump and force a full reset. This fixes the problem.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 811198dd14bc3f53f016ffba89b04eb360bcab14
Author: Kautuk Consul <consul.kautuk@gmail.com>
Date:   Mon Sep 19 16:53:12 2011 -0700

    xhci-mem.c: Check for ring->first_seg != NULL
    
    commit 0e6c7f746ea99089fb3263709075c20485a479ae upstream.
    
    There are 2 situations wherein the xhci_ring* might not get freed:
    - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and
      we goto the fail: label in xhci_ring_alloc. In this case, the ring
      will not get kfreed.
    - When the num_segs argument to xhci_ring_alloc is passed as 0 and
      we try to free the rung after that.
      ( This doesn't really happen as of now in the code but we seem to
        be entertaining num_segs=0 in xhci_ring_alloc )
    
    This should be backported to kernels as old as 2.6.31.
    
    Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 777fd194cb634f5430695c9638585e5e90785b27
Author: Rigbert Hamisch <rigbert@gmx.de>
Date:   Tue Sep 27 10:46:43 2011 +0200

    USB: qcserial: add device ID for "HP un2430 Mobile Broadband Module"
    
    commit 1bfac90d1b8e63a4d44158c3445d8fda3fb6d5eb upstream.
    
    add device ID for "HP un2430 Mobile Broadband Module"
    
    Signed-off-by: Rigbert Hamisch <rigbert@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 705cec330973ff726e5c8421a7c96a7348aa6da0
Author: Kautuk Consul <consul.kautuk@gmail.com>
Date:   Wed Sep 14 08:56:21 2011 +0530

    staging: quatech_usb2: Potential lost wakeup scenario in TIOCMIWAIT
    
    commit e8df1674d383d2ecc6efa8d7dba74c03aafdfdd7 upstream.
    
    If the usermode app does an ioctl over this serial device  by
    using TIOCMIWAIT, then the code will wait by setting the current
    task state to TASK_INTERRUPTIBLE and then calling schedule().
    This will be woken up by the qt2_process_modem_status on URB
    completion when the port_extra->shadowMSR is set to the new
    modem status.
    
    However, this could result in a lost wakeup scenario due to a race
    in the logic in the qt2_ioctl(TIOCMIWAIT) loop and the URB completion
    for new modem status in qt2_process_modem_status.
    Due to this, the usermode app's task will continue to sleep despite a
    change in the modem status.
    
    Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 72760fea8e88dac78985e6f493c1f86b90c1fc0d
Author: Matthew Daley <mattjd@gmail.com>
Date:   Fri Oct 14 18:45:05 2011 +0000

    x25: Prevent skb overreads when checking call user data
    
    commit 7f81e25befdfb3272345a2e775f520e1d515fa20 upstream.
    
    x25_find_listener does not check that the amount of call user data given
    in the skb is big enough in per-socket comparisons, hence buffer
    overreads may occur.  Fix this by adding a check.
    
    Signed-off-by: Matthew Daley <mattjd@gmail.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andrew Hendry <andrew.hendry@gmail.com>
    Acked-by: Andrew Hendry <andrew.hendry@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ec13cb15c2164ac096d71ebbe2c9869eee482d27
Author: Jean Delvare <khali@linux-fr.org>
Date:   Thu Oct 13 15:49:08 2011 -0400

    hwmon: (w83627ehf) Properly report thermal diode sensors
    
    commit bf164c58e58328c40ebc597a8ac00cc6840f9703 upstream.
    
    The w83627ehf driver is improperly reporting thermal diode sensors as
    type 2, instead of 3. This caused "sensors" and possibly other
    monitoring tools to report these sensors as "transistor" instead of
    "thermal diode".
    
    Furthermore, diode subtype selection (CPU vs. external) is only
    supported by the original W83627EHF/EHG. All later models only support
    CPU diode type, and some (NCT6776F) don't even have the register in
    question so we should avoid reading from it.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2b3b2a6721c32d4e8e13549fe83f35a1b487f05e
Author: Jeremiah Matthey <sprg86@gmail.com>
Date:   Tue Aug 23 09:44:30 2011 +0200

    HID: usbhid: Add support for SiGma Micro chip
    
    commit f5e4282586dc0c9dab8c7d32e6c43aa07f68586b upstream.
    
    Patch to add SiGma Micro-based keyboards (1c4f:0002) to hid-quirks.
    
    These keyboards dont seem to allow the records to be initialized, and hence a
    timeout occurs when the usbhid driver attempts to initialize them. The patch
    just adds the signature for these keyboards to the hid-quirks list with the
    setting HID_QUIRK_NO_INIT_REPORTS. This removes the 5-10 second wait for the
    timeout to occur.
    
    Signed-off-by: Jeremiah Matthey <sprg86@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ca1b1bfef7afbf2149a84717f710cc29c2d7abc9
Author: Mark Nelson <mdnelson8@gmail.com>
Date:   Mon Jun 27 16:33:44 2011 +1000

    ahci: Enable SB600 64bit DMA on Asus M3A
    
    commit 3c4aa91f21f65b7b40bdfb015eacbcb8453ccae2 upstream.
    
    Like e65cc194f7628ecaa02462f22f42fb09b50dcd49 this patch enables 64bit DMA
    for the AHCI SATA controller of a board that has the SB600 southbridge. In
    this case though we're enabling 64bit DMA for the Asus M3A motherboard. It
    is a new enough board that all of the BIOS releases since the initial
    release (0301 from 2007-10-22) work correctly with 64bit DMA enabled.
    
    Signed-off-by: Mark Nelson <mdnelson8@gmail.com>
    Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 056fe9ee6160d10853370b57349fab3aa63f3507
Author: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
Date:   Thu Sep 22 08:32:23 2011 -0700

    libsas: fix panic when single phy is disabled on a wide port
    
    commit a73914c35b05d80f8ce78288e10056c91090b666 upstream.
    
    When a wide port is being utilized to a target, if one disables only one
    of the
    phys, we get an OS crash:
    
    BUG: unable to handle kernel NULL pointer dereference at
    0000000000000238
    IP: [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
    PGD 4103f5067 PUD 41dba9067 PMD 0
    Oops: 0002 [#1] SMP
    last sysfs file: /sys/bus/pci/slots/5/address
    CPU 0
    Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
    ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
    auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
    llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
    dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
    iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
    jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
    libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
    
    Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
    ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
    auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
    llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
    dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
    iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
    jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
    libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
    Pid: 5146, comm: scsi_wq_5 Not tainted
    2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server
    RIP: 0010:[<ffffffff814ca9b1>]  [<ffffffff814ca9b1>]
    mutex_lock+0x21/0x50
    RSP: 0018:ffff8803e4e33d30  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238
    RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
    R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0
    FS:  0000000000000000(0000) GS:ffff880028200000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task
    ffff8803e4e294a0)
    Stack:
     ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e
    <0> ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00
    <0> ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200
    Call Trace:
     [<ffffffffa001f06e>] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas]
     [<ffffffffa0032b6c>] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas]
     [<ffffffffa0034914>] sas_ex_revalidate_domain+0x204/0x330 [libsas]
     [<ffffffffa00307f0>] ? sas_revalidate_domain+0x0/0x90 [libsas]
     [<ffffffffa0030855>] sas_revalidate_domain+0x65/0x90 [libsas]
     [<ffffffff8108c7d0>] worker_thread+0x170/0x2a0
     [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40
     [<ffffffff8108c660>] ? worker_thread+0x0/0x2a0
     [<ffffffff81091b36>] kthread+0x96/0xa0
     [<ffffffff810141ca>] child_rip+0xa/0x20
     [<ffffffff81091aa0>] ? kthread+0x0/0xa0
     [<ffffffff810141c0>] ? child_rip+0x0/0x20
    Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24
    4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df <f0> ff
    0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d
    RIP  [<ffffffff814ca9b1>] mutex_lock+0x21/0x50
     RSP <ffff8803e4e33d30>
    CR2: 0000000000000238
    
    The following patch is admittedly a band-aid, and does not solve the
    root cause, but it still is a good candidate for hardening as a pointer
    check before reference.
    
    Signed-off-by: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
    Tested-by: Jack Wang <jack_wang@usish.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b81cbf898c9f6983216bfd44ba5553c9ecd76b7d
Author: Changli Gao <xiaosuo@gmail.com>
Date:   Tue Jun 29 13:09:18 2010 +0200

    splice: direct_splice_actor() should not use pos in sd
    
    commit 2cb4b05e7647891b46b91c07c9a60304803d1688 upstream.
    
    direct_splice_actor() shouldn't use sd->pos, as sd->pos is for file reading,
    file->f_pos should be used instead.
    
    Signed-off-by: Changli Gao <xiaosuo@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3b83e963b92ac32af38b379d9bb30d84c383b40d
Author: Jouni Malinen <jouni@qca.qualcomm.com>
Date:   Wed Sep 21 16:13:07 2011 +0300

    cfg80211: Fix validation of AKM suites
    
    commit 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream.
    
    Incorrect variable was used in validating the akm_suites array from
    NL80211_ATTR_AKM_SUITES. In addition, there was no explicit
    validation of the array length (we only have room for
    NL80211_MAX_NR_AKM_SUITES).
    
    This can result in a buffer write overflow for stack variables with
    arbitrary data from user space. The nl80211 commands using the affected
    functionality require GENL_ADMIN_PERM, so this is only exposed to admin
    users.
    
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8c1addec1bf8b23dd731580329e055a189b37564
Author: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
Date:   Thu Sep 1 06:11:17 2011 -0700

    libsas: fix failure to revalidate domain for anything but the first expander child.
    
    commit 24926dadc41cc566e974022b0e66231b82c6375f upstream.
    
    In an enclosure model where there are chaining expanders to a large body
    of storage, it was discovered that libsas, responding to a broadcast
    event change, would only revalidate the domain of first child expander
    in the list.
    
    The issue is that the pointer value to the discovered source device was
    used to break out of the loop, rather than the content of the pointer.
    
    This still remains non-compliant as the revalidate domain code is
    supposed to loop through all child expanders, and not stop at the first
    one it finds that reports a change count. However, the design of this
    routine does not allow multiple device discoveries and that would be a
    more complicated set of patches reserved for another day. We are fixing
    the glaring bug rather than refactoring the code.
    
    Signed-off-by: Mark Salyzyn <msalyzyn@us.xyratex.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c743934b2b885314597413bb03c42eabba33f058
Author: Vasily Averin <vvs@parallels.com>
Date:   Fri Sep 2 19:31:46 2011 +0400

    aacraid: reset should disable MSI interrupt
    
    commit d0efab26f89506387a1bde898556660e06d7eb15 upstream.
    
    scsi reset on hardware with enabled MSI interrupts generates WARNING message
    
    [11027.798722] aacraid: Host adapter abort request (0,0,0,0)
    [11027.798814] aacraid: Host adapter reset request. SCSI hang ?
    [11087.762237] aacraid: SCSI bus appears hung
    [11135.082543] ------------[ cut here ]------------
    [11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290()
    
    Signed-off-by: Vasily Averin <vvs@sw.ru>
    Acked-by: Mark Salyzyn <mark_salyzyn@us.xyratex.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6e66366450c622c3d551a5b0ac8c820d56a7369c
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Sun Sep 18 18:56:20 2011 +0400

    3w-9xxx: fix iommu_iova leak
    
    commit 96067723e46b0dd24ae7b934085ab4eff4d26a1b upstream.
    
    Following reports on the list, it looks like the 3e-9xxx driver will leak dma
    mappings every time we get a transient queueing error back from the card.
    This is because it maps the sg list in the routine that sends the command, but
    doesn't unmap again in the transient failure path (even though the command is
    sent back to the block layer).  Fix by unmapping before returning the status.
    
    Reported-by: Chris Boot <bootc@bootc.net>
    Tested-by: Chris Boot <bootc@bootc.net>
    Acked-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f48f8fe35ad1e72cef6deb78fd512527520acab1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 26 10:41:21 2011 +0200

    ALSA: hda/realtek - Avoid bogus HP-pin assignment
    
    commit 5fe6e0151dbd969f5fbcd94d05c968b76d76952b upstream.
    
    When the headphone pin is assigned as primary output to line_out_pins[],
    the automatic HP-pin assignment by ASSID must be suppressed.  Otherwise
    a wrong pin might be assigned to the headphone and breaks the auto-mute.
    
    Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 51f01bfbf9012b165e9aeb72e016fd78033b99ce
Author: Michael Chan <mchan@broadcom.com>
Date:   Wed Jun 8 19:29:35 2011 +0000

    cnic: Improve NETDEV_UP event handling
    
    commit db1d350fcb156b58f66a67680617077bcacfe6fc upstream.
    
    During NETDEV_UP, we use symbol_get() to get the net driver's cnic
    probe function.  This sometimes doesn't work if NETDEV_UP happens
    right after NETDEV_REGISTER and the net driver is still running module
    init code.  As a result, the cnic device may not be discovered.  We
    fix this by probing on all NETDEV events if the device's netif_running
    state is up.
    
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3e8264dbebf6026b4d3a778414738d5f8617c54c
Author: Mike Christie <michaelc@cs.wisc.edu>
Date:   Fri Jun 24 15:11:55 2011 -0500

    libiscsi_tcp: fix LLD data allocation
    
    commit 74dcd0ec735ba9c5bef254b2f6e53068cf3f9ff0 upstream.
    
    Have libiscsi_tcp have upper layers allocate the LLD data
    along with the iscsi_cls_conn struct, so it is refcounted.
    
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8cef0aa080f3f7c443f1380f5b1fba63859e757a
Author: Peter Huewe <huewe.external.infineon@googlemail.com>
Date:   Thu Sep 15 14:47:42 2011 -0300

    TPM: Zero buffer after copying to userspace
    
    commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 upstream.
    
    Since the buffer might contain security related data it might be a good idea to
    zero the buffer after we have copied it to userspace.
    
    This got assigned CVE-2011-1162.
    
    Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit f891a7b01eed6b941627f5049b439da368d76fa3
Author: Peter Huewe <huewe.external.infineon@googlemail.com>
Date:   Thu Sep 15 14:37:43 2011 -0300

    TPM: Call tpm_transmit with correct size
    
    commit 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 upstream.
    
    This patch changes the call of tpm_transmit by supplying the size of the
    userspace buffer instead of TPM_BUFSIZE.
    
    This got assigned CVE-2011-1161.
    
    [The first hunk didn't make sense given one could expect
     way less data than TPM_BUFSIZE, so added tpm_transmit boundary
     check over bufsiz instead
     The last parameter of tpm_transmit() reflects the amount
     of data expected from the device, and not the buffer size
     being supplied to it. It isn't ideal to parse it directly,
     so we just set it to the maximum the input buffer can handle
     and let the userspace API to do such job.]
    
    Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e4e132aa6024dde90b1bd685d8bea876b7434abf
Author: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Date:   Tue Jul 5 21:50:18 2011 +0000

    hvc_console: Improve tty/console put_chars handling
    
    commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 upstream.
    
    Currently, the hvc_console_print() function drops console output if the
    hvc backend's put_chars() returns 0.  This patch changes this behavior
    to allow a retry through returning -EAGAIN.
    
    This change also affects the hvc_push() function.  Both functions are
    changed to handle -EAGAIN and to retry the put_chars() operation.
    
    If a hvc backend returns -EAGAIN, the retry handling differs:
    
      - hvc_console_print() spins to write the complete console output.
      - hvc_push() behaves the same way as for returning 0.
    
    Now hvc backends can indirectly control the way how console output is
    handled through the hvc console layer.
    
    Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
    Acked-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dcf7e701ae30c36f62239a00d1118b41a0ae33a6
Author: Marek Vasut <marek.vasut@gmail.com>
Date:   Wed Jul 20 05:57:04 2011 +0000

    ASIX: Add AX88772B USB ID
    
    commit 308859097831831a979f2e82cbeef0a94f438080 upstream.
    
    This device can be found in Acer Iconia TAB W500 tablet dock.
    
    Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 53d9adf97e97e49e3674998ce56da01676febba5
Author: Michal Sroczynski <msroczyn@gmail.com>
Date:   Tue Jul 5 21:53:35 2011 +0200

    USB: PL2303: correctly handle baudrates above 115200
    
    commit 8d48fdf689fed2c73c493e5146d1463689246442 upstream.
    
    PL2303: correctly handle baudrates above 115200
    
    Signed-off-by: Michal Sroczynski <msroczyn@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6405eedf12c90972e748baa4b283864018f890df
Author: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Date:   Wed Sep 14 14:28:17 2011 +0530

    wireless: Reset beacon_found while updating regulatory
    
    commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream.
    
    During the association, the regulatory is updated by country IE
    that reaps the previously found beacons. The impact is that
    after a STA disconnects *or* when for any reason a regulatory
    domain change happens the beacon hint flag is not cleared
    therefore preventing future beacon hints to be learned.
    This is important as a regulatory domain change or a restore
    of regulatory settings would set back the passive scan and no-ibss
    flags on the channel. This is the right place to do this given that
    it covers any regulatory domain change.
    
    Reviewed-by: Luis R. Rodriguez <mcgrof@gmail.com>
    Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e8e310bd4894a0d6c2c75b1ab65103cc4bc8aceb
Author: Manual Munz <freifunk@somakoma.de>
Date:   Sun Sep 18 18:24:03 2011 -0500

    b43: Fix beacon problem in ad-hoc mode
    
    commit 8c23516fbb209ccf8f8c36268311c721faff29ee upstream.
    
    In ad-hoc mode, driver b43 does not issue beacons.
    
    Signed-off-by: Manual Munz <freifunk@somakoma.de>
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3195f9a0017e12792fd06b79538c04cf76e3ecad
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Aug 23 07:21:28 2011 -0400

    cifs: fix possible memory corruption in CIFSFindNext
    
    commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.
    
    The name_len variable in CIFSFindNext is a signed int that gets set to
    the resume_name_len in the cifs_search_info. The resume_name_len however
    is unsigned and for some infolevels is populated directly from a 32 bit
    value sent by the server.
    
    If the server sends a very large value for this, then that value could
    look negative when converted to a signed int. That would make that
    value pass the PATH_MAX check later in CIFSFindNext. The name_len would
    then be used as a length value for a memcpy. It would then be treated
    as unsigned again, and the memcpy scribbles over a ton of memory.
    
    Fix this by making the name_len an unsigned value in CIFSFindNext.
    
    Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a2f9da8f5ac98347c315c2b2fdcf1c6fa054b5c0
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Sep 14 13:22:54 2011 +0200

    ALSA: HDA: Cirrus - fix "Surround Speaker" volume control name
    
    commit 2e1210bc3d065a6e26ff5fef228a9a7e08921d2c upstream.
    
    This patch fixes "Surround Speaker Playback Volume" being cut off.
    (Commit b4dabfc452a10 was probably meant to fix this, but it fixed
    only the "Switch" name, not the "Volume" name.)
    
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c1601d1bba798e168c010889df5cbc2a3a8b7e93
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Sun Sep 4 08:18:18 2011 -0700

    ASoC: Fix reporting of partial jack updates
    
    commit 747da0f80e566500421bd7760b2e050fea3fde5e upstream.
    
    We need to report the entire jack state to the core jack code, not just
    the bits that were being updated by the caller, otherwise the status
    reported by other detection methods will be omitted from the state seen
    by userspace.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4bf38f8cbdec598e77f8f28910256e16913fcdbb
Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date:   Tue Aug 30 20:58:56 2011 -0400

    e1000: Fix driver to be used on PA RISC C8000 workstations
    
    commit e2faeec2de9e2c73958e6ea6065dde1e8cd6f3a2 upstream.
    
    The checksum field in the EEPROM on HPPA is really not a
    checksum but a signature (0x16d6).  So allow 0x16d6 as the
    matching checksum on HPPA systems.
    
    This issue is present on longterm/stable kernels, I have
    verified that this patch is applicable back to at least
    2.6.32.y kernels.
    
    v2- changed ifdef to use CONFIG_PARISC instead of __hppa__
    
    CC: Guy Martin <gmsoft@tuxicoman.be>
    CC: Rolf Eike Beer <eike-kernel@sf-tec.de>
    CC: Matt Turner <mattst88@gmail.com>
    Reported-by: Mikulas Patocka <mikulas@artax.kerlin.mff.cuni.cz>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 17bf51911b8bb8ebfaeaadc66090912026fc5d72
Author: Andrew Vasquez <andrew.vasquez@qlogic.com>
Date:   Tue Aug 16 11:29:28 2011 -0700

    qla2xxx: Correct inadvertent loop state transitions during port-update handling.
    
    commit 58b48576966ed0afd3f63ef17480ec12748a7119 upstream.
    
    Transitioning to a LOOP_UPDATE loop-state could cause the driver
    to miss normal link/target processing.  LOOP_UPDATE is a crufty
    artifact leftover from at time the driver performed it's own
    internal command-queuing.  Safely remove this state.
    
    Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
    Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>

commit a435bf341fba2cfb3c366a2946dae41435e7a85b
Author: Randy Dunlap <randy.dunlap@oracle.com>
Date:   Tue Jun 21 20:32:53 2011 -0700

    irda: fix smsc-ircc2 section mismatch warning
    
    commit f470e5ae34d68880a38aa79ee5c102ebc2a1aef6 upstream.
    
    Fix section mismatch warning:
    
    WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0x1a7): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open()
    
    Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 190ded24998b6adf918d99577cc6cdfa5a4cd81a
Author: Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com>
Date:   Wed Jun 29 18:06:33 2011 -0700

    net/9p: Fix the msize calculation.
    
    commit c9ffb05ca5b5098d6ea468c909dd384d90da7d54 upstream.
    
    msize represents the maximum PDU size that includes P9_IOHDRSZ.
    
    Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com>
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d0db378ba6a4f6e2d863666ab5c56b5a436223d4
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Mon Jul 11 16:40:58 2011 +0000

    fs/9p: Fid is not valid after a failed clunk.
    
    commit 5034990e28efb2d232ee82443a9edd62defd17ba upstream.
    
    free the fid even in case of failed clunk.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit fd319bb5c7fbe886389e19f8c530ee9a644f9619
Author: Eric Van Hensbergen <ericvh@gmail.com>
Date:   Wed Jul 13 19:12:18 2011 -0500

    net/9p: fix client code to fail more gracefully on protocol error
    
    commit b85f7d92d7bd7e3298159e8b1eed8cb8cbbb0348 upstream.
    
    There was a BUG_ON to protect against a bad id which could be dealt with
    more gracefully.
    
    Reported-by: Natalie Orlin <norlin@us.ibm.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c28f366a6ef9b6e14e069e7d750c32d73544444e
Author: NeilBrown <neilb@suse.de>
Date:   Sat Sep 10 17:21:28 2011 +1000

    md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.
    
    commit 27a7b260f71439c40546b43588448faac01adb93 upstream.
    
    0.90 metadata uses an unsigned 32bit number to count the number of
    kilobytes used from each device.
    This should allow up to 4TB per device.
    However we multiply this by 2 (to get sectors) before casting to a
    larger type, so sizes above 2TB get truncated.
    
    Also we allow rdev->sectors to be larger than 4TB, so it is possible
    for the array to be resized larger than the metadata can handle.
    So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in
    used.
    
    Also the sanity check at the end of super_90_load should include level
    1 as it used ->size too. (RAID0 and Linear don't use ->size at all).
    
    Reported-by: Pim Zandbergen <P.Zandbergen@macroscoop.nl>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c9829a93def3b31a616dc2e5908f0c44af871f9d
Author: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Date:   Tue Jul 12 15:58:53 2011 +0530

    ARM: davinci: da850 EVM: read mac address from SPI flash
    
    commit 810198bc9c109489dfadc57131c5183ce6ad2d7d upstream.
    
    DA850/OMAP-L138 EMAC driver uses random mac address instead of
    a fixed one because the mac address is not stuffed into EMAC
    platform data.
    
    This patch provides a function which reads the mac address
    stored in SPI flash (registered as MTD device) and populates the
    EMAC platform data. The function which reads the mac address is
    registered as a callback which gets called upon addition of MTD
    device.
    
    NOTE: In case the MAC address stored in SPI flash is erased, follow
    the instructions at [1] to restore it.
    
    [1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
    
    Modifications in v2:
    Guarded registering the mtd_notifier only when MTD is enabled.
    Earlier this was handled using mtd_has_partitions() call, but
    this has been removed in Linux v3.0.
    
    Modifications in v3:
    a. Guarded da850_evm_m25p80_notify_add() function and
       da850evm_spi_notifier structure with CONFIG_MTD macros.
    b. Renamed da850_evm_register_mtd_user() function to
       da850_evm_setup_mac_addr() and removed the struct mtd_notifier
       argument to this function.
    c. Passed the da850evm_spi_notifier structure to register_mtd_user()
       function.
    
    Modifications in v4:
    Moved the da850_evm_setup_mac_addr() function within the first
    CONFIG_MTD ifdef construct.
    
    Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 385e366ebd9914d2cf1dfcc840efec070484c154
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Sep 1 09:48:27 2011 -0400

    xen/smp: Warn user why they keel over - nosmp or noapic and what to use instead.
    
    commit ed467e69f16e6b480e2face7bc5963834d025f91 upstream.
    
    We have hit a couple of customer bugs where they would like to
    use those parameters to run an UP kernel - but both of those
    options turn of important sources of interrupt information so
    we end up not being able to boot. The correct way is to
    pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and
    the kernel will patch itself to be a UP kernel.
    
    Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308
    
    Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 51881948566652bea9b71f4c9db398831d3d1604
Author: Igor Mammedov <imammedo@redhat.com>
Date:   Thu Sep 1 13:46:55 2011 +0200

    xen: x86_32: do not enable iterrupts when returning from exception in interrupt context
    
    commit d198d499148a0c64a41b3aba9e7dd43772832b91 upstream.
    
    If vmalloc page_fault happens inside of interrupt handler with interrupts
    disabled then on exit path from exception handler when there is no pending
    interrupts, the following code (arch/x86/xen/xen-asm_32.S:112):
    
    	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
    	sete XEN_vcpu_info_mask(%eax)
    
    will enable interrupts even if they has been previously disabled according to
    eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99)
    
    	testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp)
    	setz XEN_vcpu_info_mask(%eax)
    
    Solution is in setting XEN_vcpu_info_mask only when it should be set
    according to
    	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
    but not clearing it if there isn't any pending events.
    
    Reproducer for bug is attached to RHBZ 707552
    
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ce59b9c3178f2786f08ce424d1db712dc1e6bc06
Author: Sonny Rao <sonnyrao@us.ibm.com>
Date:   Mon May 10 15:13:41 2010 +0000

    powerpc/pci: Check devices status property when scanning OF tree
    
    commit 5b339bdf164d8aee394609768f7e2e4415b0252a upstream.
    
    We ran into an issue where it looks like we're not properly ignoring a
    pci device with a non-good status property when we walk the device tree
    and instanciate the Linux side PCI devices.
    
    However, the EEH init code does look for the property and disables EEH
    on these devices. This leaves us in an inconsistent where we are poking
    at a supposedly bad piece of hardware and RTAS will block our config
    cycles because EEH isn't enabled anyway.
    
    Signed-of-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1badd98ea79b7b20fb4ddfea110d1bb99c33a55f
Author: Yang Li <leoli@freescale.com>
Date:   Wed Dec 16 20:18:11 2009 +0000

    powerpc/mpic: Fix problem that affinity is not updated
    
    commit 38e1313fc753482b93aa6c6f11cfbd43a5bcd963 upstream.
    
    Since commit 57b150cce8e004ddd36330490a68bfb59b7271e9, desc->affinity
    of an irq is changed after calling desc->chip->set_affinity.
    Therefore we need to fix the irq_choose_cpu() not to depend on the
    desc->affinity for new mask.
    
    Signed-off-by: Jiajun Wu <b06378@freescale.com>
    Signed-off-by: Li Yang <leoli@freescale.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 372994e9fd5cadbacdfcc8724b590193d136c947
Author: NeilBrown <neilb@suse.de>
Date:   Thu Aug 25 14:43:53 2011 +1000

    md/linear: avoid corrupting structure while waiting for rcu_free to complete.
    
    commit 1b6afa17581027218088a18a9ceda600e0ddba7a upstream.
    
    I don't know what I was thinking putting 'rcu' after a dynamically
    sized array!  The array could still be in use when we call rcu_free()
    (That is the point) so we mustn't corrupt it.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 10ae01e212fa102b65debed5b8ef7549917e605a
Author: Marek Marczykowski <marmarek@mimuw.edu.pl>
Date:   Tue May 3 12:04:52 2011 -0400

    xen-blkfront: fix data size for xenbus_gather in blkfront_connect
    
    commit 4352b47ab7918108b389a48d2163c9a4c2aaf139 upstream.
    
    barrier variable is int, not long. This overflow caused another variable
    override: "err" (in PV code) and "binfo" (in xenlinux code -
    drivers/xen/blkfront/blkfront.c). The later caused incorrect device
    flags (RO/removable etc).
    
    Signed-off-by: Marek Marczykowski <marmarek@mimuw.edu.pl>
    Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
    [v1: Changed title]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 141ec4b17b6744b06ee0516d187170a29a101560
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Mon Jan 24 12:08:48 2011 +0000

    GRO: fix merging a paged skb after non-paged skbs
    
    commit d1dc7abf2fafa34b0ffcd070fd59405aa9c0a4d8 upstream.
    
    Suppose that several linear skbs of the same flow were received by GRO. They
    were thus merged into one skb with a frag_list. Then a new skb of the same flow
    arrives, but it is a paged skb with data starting in its frags[].
    
    Before adding the skb to the frag_list skb_gro_receive() will of course adjust
    the skb to throw away the headers. It correctly modifies the page_offset and
    size of the frag, but it leaves incorrect information in the skb:
     ->data_len is not decreased at all.
     ->len is decreased only by headlen, as if no change were done to the frag.
    Later in a receiving process this causes skb_copy_datagram_iovec() to return
    -EFAULT and this is seen in userspace as the result of the recv() syscall.
    
    In practice the bug can be reproduced with the sfc driver. By default the
    driver uses an adaptive scheme when it switches between using
    napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is
    reproduced when under rx load with enough successful GRO merging the driver
    decides to switch from the former to the latter.
    
    Manual control is also possible, so reproducing this is easy with netcat:
     - on machine1 (with sfc): nc -l 12345 > /dev/null
     - on machine2: nc machine1 12345 < /dev/zero
     - on machine1:
       echo 1 > /sys/module/sfc/parameters/rx_alloc_method  # use skbs
       echo 2 > /sys/module/sfc/parameters/rx_alloc_method  # use pages
     - See that nc has quit suddenly.
    
    [v2: Modified by Eric Dumazet to avoid advancing skb->data past the end
         and to use a temporary variable.]
    
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 570bd39ac8505e57b1d62e56b84eea9de8473c15
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Tue Aug 30 15:35:11 2011 -0700

    Revert "x86, hotplug: Use mwait to offline a processor, fix the legacy case"
    
    This reverts commit 226917b0735f31cf5c704e07fdd590d99bbfae58 (upstream
    ea53069231f9317062910d6e772cca4ce93de8c8 and
    a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a and
    ce5f68246bf2385d6174856708d0b746dc378f20 all mushed together) as
    Jonathan Nieder reports that this causes a regression on some hardware.
    
    More details can be found at http://bugs.debian.org/622259
    
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 71c6bd5af2d984fadd81611ad643bda52e82ad79
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu May 27 16:14:30 2010 -0700

    ipv6: Add GSO support on forwarding path
    
    commit 0aa68271510ae2b221d4b60892103837be63afe4 upstream.
    
    Currently we disallow GSO packets on the IPv6 forward path.
    This patch fixes this.
    
    Note that I discovered that our existing GSO MTU checks (e.g.,
    IPv4 forwarding) are buggy in that they skip the check altogether,
    when they really should be checking gso_size + header instead.
    
    I have also been lazy here in that I haven't bothered to segment
    the GSO packet by hand before generating an ICMP message.  Someone
    should add that to be 100% correct.
    
    Reported-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
    Signed-off-by: Faidon Liambotis <paravoid@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3b454d6b495fa853304741503db0b23f0542e3ef
Author: Sridhar Samudrala <sri@us.ibm.com>
Date:   Sat Jan 23 02:02:21 2010 -0800

    net: Fix IPv6 GSO type checks in Intel ethernet drivers
    
    commit 8e1e8a4779cb23c1d9f51e9223795e07ec54d77a upstream.
    
    Found this problem when testing IPv6 from a KVM guest to a remote
    host via e1000e device on the host.
    The following patch fixes the check for IPv6 GSO packet in Intel
    ethernet drivers to use skb_is_gso_v6(). SKB_GSO_DODGY is also set
    when packets are forwarded from a guest.
    
    Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Faidon Liambotis <paravoid@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c5ed15616ec3dc395107c3c8c760039ae9edfec8
Author: Stratos Psomadakis <psomas@gentoo.org>
Date:   Tue Aug 30 17:48:08 2011 +0300

    Fix broken backport for IPv6 tunnels
    
    Fix broken backport for IPv6 tunnels in 2.6.32-longterm kernels.
    
    upstream commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978 ("tunnels: fix
    netns vs proto registration ordering") , which was included in
    2.6.32.44-longterm, was not backported correctly, and results in a NULL
    pointer dereference in ip6_tunnel.c for longterm kernels >=2.6.32.44
    
    Use [un]register_pernet_gen_device() instead of
    [un]register_pernet_device() to fix it.
    
    Signed-off-by: Stratos Psomadakis <psomas@gentoo.org>
    Cc: Wolfgang Walter <wolfgang.walter@stwm.de>
    Cc: Tim Gardner <tim.gardner@canonical.com>
    Cc: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit abc7edfb03efd63cf15c98b1b5984e4dcf076edd
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Aug 17 22:14:57 2011 +0000

    sparc: fix array bounds error setting up PCIC NMI trap
    
    commit 4a0342ca8e8150bd47e7118a76e300692a1b6b7b upstream.
    
      CC      arch/sparc/kernel/pcic.o
    arch/sparc/kernel/pcic.c: In function 'pcic_probe':
    arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
    arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
    arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
    arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
    arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
    arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
    cc1: all warnings being treated as errors
    
    I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
    the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
    to be 4 instructions long and I presume from the usage that instructions are
    int sized.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 910098ec61a6b248c7bd4da4cd40bf76330fd268
Author: David S. Miller <davem@davemloft.net>
Date:   Sat Aug 20 17:14:54 2011 -0700

    sparc: Allow handling signals when stack is corrupted.
    
    commit 5598473a5b40c47a8c5349dd2c2630797169cf1a upstream.
    
    If we can't push the pending register windows onto the user's stack,
    we disallow signal delivery even if the signal would be delivered on a
    valid seperate signal stack.
    
    Add a register window save area in the signal frame, and store any
    unsavable windows there.
    
    On sigreturn, if any windows are still queued up in the signal frame,
    try to push them back onto the stack and if that fails we kill the
    process immediately.
    
    This allows the debug/tst-longjmp_chk2 glibc test case to pass.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3fe9d0a904fb32444a9c7f009c3644176b5728a2
Author: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Date:   Fri Aug 19 12:04:20 2011 +0000

    atm: br2684: Fix oops due to skb->dev being NULL
    
    commit fbe5e29ec1886967255e76946aaf537b8cc9b81e upstream.
    
    This oops have been already fixed with commit
    
        27141666b69f535a4d63d7bc6d9e84ee5032f82a
    
        atm: [br2684] Fix oops due to skb->dev being NULL
    
        It happens that if a packet arrives in a VC between the call to open it on
        the hardware and the call to change the backend to br2684, br2684_regvcc
        processes the packet and oopses dereferencing skb->dev because it is
        NULL before the call to br2684_push().
    
    but have been introduced again with commit
    
        b6211ae7f2e56837c6a4849316396d1535606e90
    
        atm: Use SKB queue and list helpers instead of doing it by-hand.
    
    Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 165b1d34623bdc5c2e7f8873a95425462b8cd135
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Aug 12 14:02:04 2011 +0200

    rt2x00: do not drop usb dev reference counter on suspend
    
    commit 543cc38c8fe86deba4169977c61eb88491036837 upstream.
    
    When hibernating ->resume may not be called by usb core, but disconnect
    and probe instead, so we do not increase the counter after decreasing
    it in ->supend. As a result we free memory early, and get crash when
    unplugging usb dongle.
    
    BUG: unable to handle kernel paging request at 6b6b6b9f
    IP: [<c06909b0>] driver_sysfs_remove+0x10/0x30
    *pdpt = 0000000034f21001 *pde = 0000000000000000
    Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO
    EIP: 0060:[<c06909b0>] EFLAGS: 00010202 CPU: 1
    EIP is at driver_sysfs_remove+0x10/0x30
    EAX: 6b6b6b6b EBX: f52bba34 ECX: 00000000 EDX: 6b6b6b6b
    ESI: 6b6b6b6b EDI: c0a0ea20 EBP: f61c9e68 ESP: f61c9e64
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process khubd (pid: 20, ti=f61c8000 task=f6138270 task.ti=f61c8000)
    Call Trace:
     [<c06909ef>] __device_release_driver+0x1f/0xa0
     [<c0690b20>] device_release_driver+0x20/0x40
     [<c068fd64>] bus_remove_device+0x84/0xe0
     [<c068e12a>] ? device_remove_attrs+0x2a/0x80
     [<c068e267>] device_del+0xe7/0x170
     [<c06d93d4>] usb_disconnect+0xd4/0x180
     [<c06d9d61>] hub_thread+0x691/0x1600
     [<c0473260>] ? wake_up_bit+0x30/0x30
     [<c0442a39>] ? complete+0x49/0x60
     [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
     [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
     [<c0472eb4>] kthread+0x74/0x80
     [<c0472e40>] ? kthread_worker_fn+0x150/0x150
     [<c0809b3e>] kernel_thread_helper+0x6/0x10
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4f122ebfda6dcf6ae59ad3c891b5f838419337f4
Author: Wang Zhi <zhi.wang@windriver.com>
Date:   Wed Aug 17 10:39:31 2011 +0800

    USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ehci_bus_resume().
    
    commit d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream.
    
    From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears
    PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host
    Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME
    bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss
    the action of clearing PORT_RESUME. This will cause unexpected long
    resume signal on USB bus.
    
    Signed-off-by: Wang Zhi <zhi.wang@windriver.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b39d45e21bc9f3a496ec46a1e41a60635e0dadc5
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date:   Thu Aug 25 11:46:58 2011 +0200

    USB: ftdi_sio: add Calao reference board support
    
    commit c96fbdd0ab97235f930ebf24b38fa42a2e3458cf upstream.
    
    Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and
    port 1 for the UART
    
    They use the same VID and PID as FTDI Chip but they program the manufacturer
    name in the eeprom
    
    So use this information to detect it
    
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Gregory Hermant <gregory.hermant@calao-systems.com>
    Cc: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>