commit 20c7bbdde3de202d847f7e9f14cbd7ffeb03e81e
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 6 11:20:40 2012 +0000

    Linux 3.2.35

commit d670ed5e12954d8fd2b9de49222b1dc5d1723340
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Dec 2 13:14:30 2012 +0000

    intel_idle: enable IVB Xeon support
    
    commit 23795e580cad5d6b73d47d51b9074ce3e58bf334 upstream.
    
    IVB Xeon currently shares the same parameters IVB client.
    
    For 3.2, add model number to the switch in intel_idle_probe(), as
    there is no device ID table.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9f1c9393d2433fa745eae6b5eabe1acef3ec5baa
Author: Len Brown <len.brown@intel.com>
Date:   Fri Jun 1 19:45:32 2012 -0400

    intel_idle: initial IVB support
    
    commit 6edab08c24f9141d69cfa4683a0a027d86ab303e upstream.
    
    From an OS point of view, IVB looks like SNB, but quicker.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    [bwh: Backported to 3.2: add model number to the switch in
     intel_idle_probe(), as there is no device ID table]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 704f66592067ef19abb87da6fd43a59e34823122
Author: Mike Galbraith <mgalbraith@suse.de>
Date:   Wed Nov 28 07:17:18 2012 +0100

    workqueue: exit rescuer_thread() as TASK_RUNNING
    
    commit 412d32e6c98527078779e5b515823b2810e40324 upstream.
    
    A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling
    off, never to be seen again.  In the case where this occurred, an exiting
    thread hit reiserfs homebrew conditional resched while holding a mutex,
    bringing the box to its knees.
    
    PID: 18105  TASK: ffff8807fd412180  CPU: 5   COMMAND: "kdmflush"
     #0 [ffff8808157e7670] schedule at ffffffff8143f489
     #1 [ffff8808157e77b8] reiserfs_get_block at ffffffffa038ab2d [reiserfs]
     #2 [ffff8808157e79a8] __block_write_begin at ffffffff8117fb14
     #3 [ffff8808157e7a98] reiserfs_write_begin at ffffffffa0388695 [reiserfs]
     #4 [ffff8808157e7ad8] generic_perform_write at ffffffff810ee9e2
     #5 [ffff8808157e7b58] generic_file_buffered_write at ffffffff810eeb41
     #6 [ffff8808157e7ba8] __generic_file_aio_write at ffffffff810f1a3a
     #7 [ffff8808157e7c58] generic_file_aio_write at ffffffff810f1c88
     #8 [ffff8808157e7cc8] do_sync_write at ffffffff8114f850
     #9 [ffff8808157e7dd8] do_acct_process at ffffffff810a268f
        [exception RIP: kernel_thread_helper]
        RIP: ffffffff8144a5c0  RSP: ffff8808157e7f58  RFLAGS: 00000202
        RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
        RDX: 0000000000000000  RSI: ffffffff8107af60  RDI: ffff8803ee491d18
        RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
        R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
        R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    
    Signed-off-by: Mike Galbraith <mgalbraith@suse.de>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 65a777980f38d7f80eb726aec2572580fb9a267d
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Thu Nov 29 13:54:34 2012 -0800

    mm: soft offline: split thp at the beginning of soft_offline_page()
    
    commit 783657a7dc20e5c0efbc9a09a9dd38e238a723da upstream.
    
    When we try to soft-offline a thp tail page, put_page() is called on the
    tail page unthinkingly and VM_BUG_ON is triggered in put_compound_page().
    
    This patch splits thp before going into the main body of soft-offlining.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Andi Kleen <andi.kleen@intel.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 39d18dc4b8b0c000fa681cbae10ac3f8a132814b
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Nov 29 13:54:23 2012 -0800

    mm: vmscan: fix endless loop in kswapd balancing
    
    commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.
    
    Kswapd does not in all places have the same criteria for a balanced
    zone.  Zones are only being reclaimed when their high watermark is
    breached, but compaction checks loop over the zonelist again when the
    zone does not meet the low watermark plus two times the size of the
    allocation.  This gets kswapd stuck in an endless loop over a small
    zone, like the DMA zone, where the high watermark is smaller than the
    compaction requirement.
    
    Add a function, zone_balanced(), that checks the watermark, and, for
    higher order allocations, if compaction has enough free memory.  Then
    use it uniformly to check for balanced zones.
    
    This makes sure that when the compaction watermark is not met, at least
    reclaim happens and progress is made - or the zone is declared
    unreclaimable at some point and skipped entirely.
    
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: George Spelvin <linux@horizon.com>
    Reported-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reported-by: Tomas Racek <tracek@redhat.com>
    Tested-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d39c325a8ac0b03c1f66a0cd0ba42073e98cde69
Author: Jianguo Wu <wujianguo@huawei.com>
Date:   Thu Nov 29 13:54:21 2012 -0800

    mm/vmemmap: fix wrong use of virt_to_page
    
    commit ae64ffcac35de0db628ba9631edf8ff34c5cd7ac upstream.
    
    I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing
    memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20.
    
    It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is
    only used for kernel direct mapping address, but sparse-vmemmap uses
    vmemmap address, so it is going wrong here.
    
      ------------[ cut here ]------------
      kernel BUG at arch/x86/mm/physaddr.c:20!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
      CPU 39
      Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ #45 QCI QSSC-S4R/QSSC-S4R
      RIP: 0010:[<ffffffff8103c908>]  [<ffffffff8103c908>] __phys_addr+0x88/0x90
      RSP: 0018:ffff8804440d7c08  EFLAGS: 00010006
      RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c
      ...
    
    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Reviewd-by: Wen Congyang <wency@cn.fujitsu.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c6cb742965c94f8d8e3c15cb1ff022509996073
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Mon Nov 26 16:29:56 2012 -0800

    futex: avoid wake_futex() for a PI futex_q
    
    commit aa10990e028cac3d5e255711fb9fb47e00700e35 upstream.
    
    Dave Jones reported a bug with futex_lock_pi() that his trinity test
    exposed.  Sometime between queue_me() and taking the q.lock_ptr, the
    lock_ptr became NULL, resulting in a crash.
    
    While futex_wake() is careful to not call wake_futex() on futex_q's with
    a pi_state or an rt_waiter (which are either waiting for a
    futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and
    futex_requeue() do not perform the same test.
    
    Update futex_wake_op() and futex_requeue() to test for q.pi_state and
    q.rt_waiter and abort with -EINVAL if detected.  To ensure any future
    breakage is caught, add a WARN() to wake_futex() if the same condition
    is true.
    
    This fix has seen 3 hours of testing with "trinity -c futex" on an
    x86_64 VM with 4 CPUS.
    
    [akpm@linux-foundation.org: tidy up the WARN()]
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Reported-by: Dave Jones <davej@redat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: John Kacur <jkacur@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a548ee1595d834f795f8c9688f516d48b0304ddf
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Nov 26 22:24:23 2012 +0100

    can: bcm: initialize ifindex for timeouts without previous frame reception
    
    commit 81b401100c01d2357031e874689f89bd788d13cd upstream.
    
    Set in the rx_ifindex to pass the correct interface index in the case of a
    message timeout detection. Usually the rx_ifindex value is set at receive
    time. But when no CAN frame has been received the RX_TIMEOUT notification
    did not contain a valid value.
    
    Reported-by: Andre Naujoks <nautsch2@googlemail.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b830a12b24fcfd9d241de936b9b11e3b23e9c23
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 23 14:03:04 2012 +0100

    jbd: Fix lock ordering bug in journal_unmap_buffer()
    
    commit 25389bb207987b5774182f763b9fb65ff08761c8 upstream.
    
    Commit 09e05d48 introduced a wait for transaction commit into
    journal_unmap_buffer() in the case we are truncating a buffer undergoing commit
    in the page stradding i_size on a filesystem with blocksize < pagesize. Sadly
    we forgot to drop buffer lock before waiting for transaction commit and thus
    deadlock is possible when kjournald wants to lock the buffer.
    
    Fix the problem by dropping the buffer lock before waiting for transaction
    commit. Since we are still holding page lock (and that is OK), buffer cannot
    disappear under us.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32eb44e290d1151e9eb26f57564dae6966190685
Author: Roland Dreier <roland@purestorage.com>
Date:   Thu Nov 22 02:00:11 2012 -0800

    block: Don't access request after it might be freed
    
    commit 893d290f1d7496db97c9471bc352ad4a11dc8a25 upstream.
    
    After we've done __elv_add_request() and __blk_run_queue() in
    blk_execute_rq_nowait(), the request might finish and be freed
    immediately.  Therefore checking if the type is REQ_TYPE_PM_RESUME
    isn't safe afterwards, because if it isn't, rq might be gone.
    Instead, check beforehand and stash the result in a temporary.
    
    This fixes crashes in blk_execute_rq_nowait() I get occasionally when
    running with lots of memory debugging options enabled -- I think this
    race is usually harmless because the window for rq to be reallocated
    is so small.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit de268a9f92b3b2504e9f87db3b4dd609aafb255f
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Nov 6 12:24:26 2012 +0100

    dm: fix deadlock with request based dm and queue request_fn recursion
    
    commit a8c32a5c98943d370ea606a2e7dc04717eb92206 upstream.
    
    Request based dm attempts to re-run the request queue off the
    request completion path. If used with a driver that potentially does
    end_io from its request_fn, we could deadlock trying to recurse
    back into request dispatch. Fix this by punting the request queue
    run to kblockd.
    
    Tested to fix a quickly reproducible deadlock in such a scenario.
    
    Acked-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 66a572596853a2180272ca6a017cc32e8a56527c
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Wed Nov 21 19:27:23 2012 +0000

    fix user-triggerable panic on parisc
    
    commit 441a179dafc0f99fc8b3a8268eef66958621082e upstream.
    
    int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                        unsigned int sigsetsize)
    {
            sigset_t old_set, new_set;
            int ret;
    
            if (set && get_sigset32(set, &new_set, sigsetsize))
    
    ...
    static int
    get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
    {
            compat_sigset_t s;
            int r;
    
            if (sz != sizeof *set) panic("put_sigset32()");
    
    In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
    will promptly panic the box.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e961f8822e342a846be1b6e0e7c1ec5f18932511
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date:   Wed Nov 21 00:19:06 2012 -0700

    ARM: Kirkwood: Update PCI-E fixup
    
    commit 1dc831bf53fddcc6443f74a39e72db5bcea4f15d upstream.
    
    - The code relies on rc_pci_fixup being called, which only happens
      when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
      this causes a booting failure with a non-obvious cause.
    - Update rc_pci_fixup to set the class properly, copying the
      more modern style from other places
    - Correct the rc_pci_fixup comment
    
    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58e104064bdb276b35ef69413e8702424ada4094
Author: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date:   Sun Nov 18 16:39:32 2012 +0000

    Dove: Fix irq_to_pmu()
    
    commit d356cf5a74afa32b40decca3c9dd88bc3cd63eb5 upstream.
    
    PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1.
    Fix the condition.  (It may have been less likely to occur had the code
    been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier
    to understand notation, and matches the normal way of thinking about
    these things.)
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a06aa3abd59c87b00c3d0a1cff1d811be285a626
Author: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date:   Sun Nov 18 16:29:44 2012 +0000

    Dove: Attempt to fix PMU/RTC interrupts
    
    commit 5d3df935426271016b895aecaa247101b4bfa35e upstream.
    
    Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
    has not been sensibly designed so that interrupts can be handled in a
    race free manner.  The PMU is one such instance.
    
    The pending (aka 'cause') register is a bunch of RW bits, meaning that
    these bits can be both cleared and set by software (confirmed on the
    Armada-510 on the cubox.)
    
    Hardware sets the appropriate bit when an interrupt is asserted, and
    software is required to clear the bits which are to be processed.  If
    we write ~(1 << bit), then we end up asserting every other interrupt
    except the one we're processing.  So, we need to do a read-modify-write
    cycle to clear the asserted bit.
    
    However, any interrupts which occur in the middle of this cycle will
    also be written back as zero, which will also clear the new interrupts.
    
    The upshot of this is: there is _no_ way to safely clear down interrupts
    in this register (and other similarly behaving interrupt pending
    registers on this device.)  The patch below at least stops us creating
    new interrupts.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5940e5b8f719f95f9c84a836ecde3f438d70419a
Author: Dave Jones <davej@redhat.com>
Date:   Thu Nov 8 16:09:27 2012 -0800

    selinux: fix sel_netnode_insert() suspicious rcu dereference
    
    commit 88a693b5c1287be4da937699cb82068ce9db0135 upstream.
    
    ===============================
    [ INFO: suspicious RCU usage. ]
    3.5.0-rc1+ #63 Not tainted
    -------------------------------
    security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 1, debug_locks = 0
    1 lock held by trinity-child1/8750:
     #0:  (sel_netnode_lock){+.....}, at: [<ffffffff812d8f8a>] sel_netnode_sid+0x16a/0x3e0
    
    stack backtrace:
    Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
    Call Trace:
     [<ffffffff810cec2d>] lockdep_rcu_suspicious+0xfd/0x130
     [<ffffffff812d91d1>] sel_netnode_sid+0x3b1/0x3e0
     [<ffffffff812d8e20>] ? sel_netnode_find+0x1a0/0x1a0
     [<ffffffff812d24a6>] selinux_socket_bind+0xf6/0x2c0
     [<ffffffff810cd1dd>] ? trace_hardirqs_off+0xd/0x10
     [<ffffffff810cdb55>] ? lock_release_holdtime.part.9+0x15/0x1a0
     [<ffffffff81093841>] ? lock_hrtimer_base+0x31/0x60
     [<ffffffff812c9536>] security_socket_bind+0x16/0x20
     [<ffffffff815550ca>] sys_bind+0x7a/0x100
     [<ffffffff816c03d5>] ? sysret_check+0x22/0x5d
     [<ffffffff810d392d>] ? trace_hardirqs_on_caller+0x10d/0x1a0
     [<ffffffff8133b09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
     [<ffffffff816c03a9>] system_call_fastpath+0x16/0x1b
    
    This patch below does what Paul McKenney suggested in the previous thread.
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Cc: Eric Paris <eparis@parisplace.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd6f4d7ed68c51ab39b55f0a7e34fdc3c8d45867
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Nov 21 08:57:58 2012 +0100

    ALSA: hda - Add support for Realtek ALC292
    
    commit af02dde8a609d8d071c4b31a82df811a55690a4a upstream.
    
    We found a new codec ID 292, and that just a simple quirk would enable
    sound output/input on this ALC292 chip.
    
    BugLink: https://bugs.launchpad.net/bugs/1081466
    Tested-by: Acelan Kao <acelan.kao@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1eafeca762f4a8d1d022bc12059543146e2d9d6
Author: Kailang Yang <kailang@realtek.com>
Date:   Sat Oct 6 17:02:30 2012 +0200

    ALSA: hda - Add new codec ALC283 ALC290 support
    
    commit 7ff34ad80b7080fafaac8efa9ef0061708eddd51 upstream.
    
    These are compatible with standard ALC269 parser.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d455b8ffb98288aff9c7b8ff5975baf9b4ea7d08
Author: Boris Ostrovsky <boris.ostrovsky@amd.com>
Date:   Thu Nov 15 13:41:50 2012 -0500

    x86, microcode, AMD: Add support for family 16h processors
    
    commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream.
    
    Add valid patch size for family 16h processors.
    
    [ hpa: promoting to urgent/stable since it is hw enabling and trivial ]
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Acked-by: Andreas Herrmann <herrmann.der.user@googlemail.com>
    Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0756cbfe25e44d7ed3c26fc48717b3f246dbb26
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Tue Nov 20 22:21:02 2012 -0800

    x86-32: Export kernel_stack_pointer() for modules
    
    commit cb57a2b4cff7edf2a4e32c0163200e9434807e0a upstream.
    
    Modules, in particular oprofile (and possibly other similar tools)
    need kernel_stack_pointer(), so export it using EXPORT_SYMBOL_GPL().
    
    Cc: Yang Wei <wei.yang@windriver.com>
    Cc: Robert Richter <robert.richter@amd.com>
    Cc: Jun Zhang <jun.zhang@intel.com>
    Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dcf771d66bd7539fbd9d3ef68ba73b6a8c7c6e01
Author: Robert Richter <robert.richter@amd.com>
Date:   Mon Sep 3 20:54:48 2012 +0200

    x86-32: Fix invalid stack address while in softirq
    
    commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.
    
    In 32 bit the stack address provided by kernel_stack_pointer() may
    point to an invalid range causing NULL pointer access or page faults
    while in NMI (see trace below). This happens if called in softirq
    context and if the stack is empty. The address at &regs->sp is then
    out of range.
    
    Fixing this by checking if regs and &regs->sp are in the same stack
    context. Otherwise return the previous stack pointer stored in struct
    thread_info. If that address is invalid too, return address of regs.
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000a
     IP: [<c1004237>] print_context_stack+0x6e/0x8d
     *pde = 00000000
     Oops: 0000 [#1] SMP
     Modules linked in:
     Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
     EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0
     EIP is at print_context_stack+0x6e/0x8d
     EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
     ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
      DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
     CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
     DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
     DR6: ffff0ff0 DR7: 00000400
     Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
     Stack:
      000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
      f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
      f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
     Call Trace:
      [<c1003723>] dump_trace+0x7b/0xa1
      [<c12dce1c>] x86_backtrace+0x40/0x88
      [<c12db712>] ? oprofile_add_sample+0x56/0x84
      [<c12db731>] oprofile_add_sample+0x75/0x84
      [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260
      [<c12dd40d>] profile_exceptions_notify+0x23/0x4c
      [<c1395034>] nmi_handle+0x31/0x4a
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c13950ed>] do_nmi+0xa0/0x2ff
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c13949e5>] nmi_stack_correct+0x28/0x2d
      [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
      [<c1003603>] ? do_softirq+0x4b/0x7f
      <IRQ>
      [<c102a06f>] irq_exit+0x35/0x5b
      [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a
      [<c1394746>] apic_timer_interrupt+0x2a/0x30
     Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
     EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
     CR2: 000000000000000a
     ---[ end trace 62afee3481b00012 ]---
     Kernel panic - not syncing: Fatal exception in interrupt
    
    V2:
    * add comments to kernel_stack_pointer()
    * always return a valid stack address by falling back to the address
      of regs
    
    Reported-by: Yang Wei <wei.yang@windriver.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Jun Zhang <jun.zhang@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17c907003db3a516453d79c2de7fd23245210c2d
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Mon Nov 19 21:17:31 2012 +0100

    radeon: add AGPMode 1 quirk for RV250
    
    commit 45171002b01b2e2ec4f991eca81ffd8430fd0aec upstream.
    
    The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
    in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
    KMS, that is). So add a quirk for it.
    
    (Change R250 to RV250 in comment for preceding quirk too.)
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 30a7bcf24d30e085d6d000f9178f24dc73ca01f6
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 19 09:11:27 2012 -0500

    drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
    
    commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream.
    
    The save struct is not initialized previously so explicitly
    mark the crtcs as not used when they are not in use.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a97aecfa37e29252cf2946937a1ea00e4dfd21da
Author: majianpeng <majianpeng@gmail.com>
Date:   Thu Nov 8 08:56:27 2012 +0800

    md: Avoid write invalid address if read_seqretry returned true.
    
    commit 35f9ac2dcec8f79d7059ce174fd7b7ee3290d620 upstream.
    
    If read_seqretry returned true and bbp was changed, it will write
    invalid address which can cause some serious problem.
    
    This bug was introduced by commit v3.0-rc7-130-g2699b67.
    So fix is suitable for 3.0.y thru 3.6.y.
    
    Reported-by: zhuwenfeng@kedacom.com
    Tested-by: zhuwenfeng@kedacom.com
    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e76f340714e8ad61cf6dba03ba460afe4bb04624
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Nov 6 17:13:44 2012 +0800

    md: Reassigned the parameters if read_seqretry returned true in func md_is_badblock.
    
    commit ab05613a0646dcc11049692d54bae76ca9ffa910 upstream.
    
    This bug was introduced by commit(v3.0-rc7-126-g2230dfe).
    So fix is suitable for 3.0.y thru 3.6.y.
    
    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 14c0699231bb44a3d492b6b5ef281e4e956ab015
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 13 17:05:14 2012 +0100

    reiserfs: Move quota calls out of write lock
    
    commit 7af11686933726e99af22901d622f9e161404e6b upstream.
    
    Calls into highlevel quota code cannot happen under the write lock. These
    calls take dqio_mutex which ranks above write lock. So drop write lock
    before calling back into quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9711ee6c9eff253a85ea67e425d74d6ff5790aad
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 13 18:25:38 2012 +0100

    reiserfs: Protect reiserfs_quota_write() with write lock
    
    commit 361d94a338a3fd0cee6a4ea32bbc427ba228e628 upstream.
    
    Calls into reiserfs journalling code and reiserfs_get_block() need to
    be protected with write lock. We remove write lock around calls to high
    level quota code in the next patch so these paths would suddently become
    unprotected.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d84f59d5a0b8630b22e186d792294924cdde5c54
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 13 16:34:17 2012 +0100

    reiserfs: Protect reiserfs_quota_on() with write lock
    
    commit b9e06ef2e8706fe669b51f4364e3aeed58639eb2 upstream.
    
    In reiserfs_quota_on() we do quite some work - for example unpacking
    tail of a quota file. Thus we have to hold write lock until a moment
    we call back into the quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.2: there is no distinction between USRQUOTA and
     GRPQUOTA mount options here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa9e08323cd85f6b94a1f57c416a9dc417561f9b
Author: Jan Kara <jack@suse.cz>
Date:   Tue Nov 13 14:55:52 2012 +0100

    reiserfs: Fix lock ordering during remount
    
    commit 3bb3e1fc47aca554e7e2cc4deeddc24750987ac2 upstream.
    
    When remounting reiserfs dquot_suspend() or dquot_resume() can be called.
    These functions take dqonoff_mutex which ranks above write lock so we have
    to drop it before calling into quota code.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e7ac9b5fc607f246a1ce62e418c0a7e5bb02c012
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Nov 18 22:27:03 2012 -0500

    sparc64: not any error from do_sigaltstack() should fail rt_sigreturn()
    
    commit fae2ae2a900a5c7bb385fe4075f343e7e2d5daa2 upstream.
    
    If a signal handler is executed on altstack and another signal comes,
    we will end up with rt_sigreturn() on return from the second handler
    getting -EPERM from do_sigaltstack().  It's perfectly OK, since we
    are not asking to change the settings; in fact, they couldn't have been
    changed during the second handler execution exactly because we'd been
    on altstack all along.  64bit sigreturn on sparc treats any error from
    do_sigaltstack() as "SIGSEGV now"; we need to switch to the same semantics
    we are using on other architectures.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad271ac21223b34db8b05091b66f1758c7e5df4a
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Wed Oct 31 16:35:30 2012 +0100

    ALSA: ua101, usx2y: fix broken MIDI output
    
    commit e99ddfde6ae0dd2662bb40435696002b590e4057 upstream.
    
    Commit 88a8516a2128 (ALSA: usbaudio: implement USB autosuspend) added
    autosuspend code to all files making up the snd-usb-audio driver.
    However, midi.c is part of snd-usb-lib and is also used by other
    drivers, not all of which support autosuspend.  Thus, calls to
    usb_autopm_get_interface() could fail, and this unexpected error would
    result in the MIDI output being completely unusable.
    
    Make it work by ignoring the error that is expected with drivers that do
    not support autosuspend.
    
    Reported-by: Colin Fletcher <colin.m.fletcher@googlemail.com>
    Reported-by: Devin Venable <venable.devin@gmail.com>
    Reported-by: Dr Nick Bailey <nicholas.bailey@glasgow.ac.uk>
    Reported-by: Jannis Achstetter <jannis_achstetter@web.de>
    Reported-by: Rui Nuno Capela <rncbc@rncbc.org>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f72ba897949f861cc95267c215ec4f8b5e9d6599
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Nov 12 22:09:46 2012 +1100

    xfs: drop buffer io reference when a bad bio is built
    
    commit d69043c42d8c6414fa28ad18d99973aa6c1c2e24 upstream.
    
    Error handling in xfs_buf_ioapply_map() does not handle IO reference
    counts correctly. We increment the b_io_remaining count before
    building the bio, but then fail to decrement it in the failure case.
    This leads to the buffer never running IO completion and releasing
    the reference that the IO holds, so at unmount we can leak the
    buffer. This leak is captured by this assert failure during unmount:
    
    XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 273
    
    This is not a new bug - the b_io_remaining accounting has had this
    problem for a long, long time - it's just very hard to get a
    zero length bio being built by this code...
    
    Further, the buffer IO error can be overwritten on a multi-segment
    buffer by subsequent bio completions for partial sections of the
    buffer. Hence we should only set the buffer error status if the
    buffer is not already carrying an error status. This ensures that a
    partial IO error on a multi-segment buffer will not be lost. This
    part of the problem is a regression, however.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Mark Tinguely <tinguely@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e68f283495084cdf869400382fefab4aecccf7d2
Author: Bing Zhao <bzhao@marvell.com>
Date:   Thu Nov 15 15:58:48 2012 -0800

    mwifiex: report error to MMC core if we cannot suspend
    
    commit dd321acddc3be1371263b8c9e6c6f2af89f63d57 upstream.
    
    When host_sleep_config command fails we should return error to
    MMC core to indicate the failure for our device.
    
    The misspelled variable is also removed as it's redundant.
    
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 154fa8dc03e900f316a0267cbf45954c2f48a6e9
Author: Bing Zhao <bzhao@marvell.com>
Date:   Thu Nov 15 15:58:47 2012 -0800

    mwifiex: fix system hang issue in cmd timeout error case
    
    commit b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 upstream.
    
    Reported by Tim Shepard:
    I was seeing sporadic failures (wedgeups), and the majority of those
    failures I saw printed the printouts in mwifiex_cmd_timeout_func with
    cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH.  When this happens, two
    minutes later I get notified that the rtcwake thread is blocked, like
    this:
          INFO: task rtcwake:3495 blocked for more than 120 seconds.
    
    To get the hung thread unblocked we wake up the cmd wait queue and
    cancel the ioctl.
    
    Reported-by: Tim Shepard <shep@laptop.org>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d61fa9bf394c53a4666c183f8d7a339e9c114bc
Author: Albert Pool <albertpool@solcon.nl>
Date:   Tue Oct 30 20:58:06 2012 +0100

    rtlwifi: rtl8192cu: Add new USB ID
    
    commit a485e827f07bfdd0762059386e6e787bed6e81ee upstream.
    
    This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102.
    Its FCC ID is the same.
    
    Signed-off-by: Albert Pool <albertpool@solcon.nl>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 715538e61d10f8a653e1149e533831f197e6fe67
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Fri Nov 2 12:30:53 2012 +0000

    fix virtual aliasing issue in get_shared_area()
    
    commit 949a05d03490e39e773e8652ccab9157e6f595b4 upstream.
    
    On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
    > Looking at the arch/parisc/kernel/sys_parisc.c implementation of
    > get_shared_area(), I do have a concern though. The function basically
    > ignores the pgoff argument, so that if one creates a shared mapping of
    > pages 0-N of a file, and then a separate shared mapping of pages 1-N
    > of that same file, both will have the same cache offset for their
    > starting address.
    >
    > This looks like this would create obvious aliasing issues. Am I
    > misreading this ? I can't understand how this could work good enough
    > to be undetected, so there must be something I'm missing here ???
    
    This turns out to be correct and we need to pay attention to the pgoff as
    well as the address when creating the virtual address for the area.
    Fortunately, the bug is rarely triggered as most applications which use pgoff
    tend to use large values (git being the primary one, and it uses pgoff in
    multiples of 16MB) which are larger than our cache coherency modulus, so the
    problem isn't often seen in practise.
    
    Reported-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 183b8794f7e2ec03fbbf915343cee9e099900307
Author: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Date:   Tue Nov 13 18:43:03 2012 +0100

    mac80211: deinitialize ibss-internals after emptiness check
    
    commit b78a4932f5fb11fadf41e69c606a33fa6787574c upstream.
    
    The check whether the IBSS is active and can be removed should be
    performed before deinitializing the fields used for the check/search.
    Otherwise, the configured BSS will not be found and removed properly.
    
    To make it more clear for the future, rename sdata->u.ibss to the
    local pointer ifibss which is used within the checks.
    
    This behaviour was introduced by
    f3209bea110cade12e2b133da8b8499689cb0e2e
    ("mac80211: fix IBSS teardown race")
    
    Cc: Ignacy Gawedzki <i@lri.fr>
    Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 733dcd5a3d61164b794d461750aed607cd46120d
Author: Maciej Patelczyk <maciej.patelczyk@intel.com>
Date:   Mon Oct 15 14:29:03 2012 +0200

    isci: copy fis 0x34 response into proper buffer
    
    commit 49bd665c5407a453736d3232ee58f2906b42e83c upstream.
    
    SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
    Device to Host (FIS 0x34) frame Initiator resets phy.
    In the frame handler routine response (FIS 0x34) was copied into wrong
    buffer and upper layer did not receive any answer which resulted in
    timeout and reset.
    This patch corrects this bug.
    
    Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e3bb00e3b611c48b83730c880d8406c35de5bb4b
Author: Thomas Betker <thomas.betker@freenet.de>
Date:   Wed Oct 17 22:59:30 2012 +0200

    jffs2: Fix lock acquisition order bug in jffs2_write_begin
    
    commit 5ffd3412ae5536a4c57469cb8ea31887121dcb2e upstream.
    
    jffs2_write_begin() first acquires the page lock, then f->sem. This
    causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first
    acquires f->sem, then the page lock:
    
    jffs2_garbage_collect_live
        mutex_lock(&f->sem)                         (A)
        jffs2_garbage_collect_dnode
            jffs2_gc_fetch_page
                read_cache_page_async
                    do_read_cache_page
                        lock_page(page)             (B)
    
    jffs2_write_begin
        grab_cache_page_write_begin
            find_lock_page
                lock_page(page)                     (B)
        mutex_lock(&f->sem)                         (A)
    
    We fix this by restructuring jffs2_write_begin() to take f->sem before
    the page lock. However, we make sure that f->sem is not held when
    calling jffs2_reserve_space(), as this is not permitted by the locking
    rules.
    
    The deadlock above was observed multiple times on an SoC with a dual
    ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred
    when using scp to copy files from a host system to the ARM target
    system. The fix was heavily tested on the same target system.
    
    Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use D1(printk(KERN_DEBUG ...)) instead of jffs2_dbg(1, ...)]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c714d5ebaa83ad49965b17b5aa8c8e732b27b60d
Author: Jiri Engelthaler <engycz@gmail.com>
Date:   Thu Sep 20 16:49:50 2012 +0200

    mtd: slram: invalid checking of absolute end address
    
    commit c36a7ff4578ab6294885aef5ef241aeec4cdb1f0 upstream.
    
    Fixed parsing end absolute address.
    
    Signed-off-by: Jiri Engelthaler <engycz@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 016ede1a94fbd90c2a24a82599859f9e46e3c298
Author: Sachin Kamat <sachin.kamat@linaro.org>
Date:   Tue Sep 25 15:27:13 2012 +0530

    mtd: ofpart: Fix incorrect NULL check in parse_ofoldpart_partitions()
    
    commit 5a6ea4af0907f995dc06df21a9c9ef764c7cd3bc upstream.
    
    The pointer returned by kzalloc should be tested for NULL
    to avoid potential NULL pointer dereference later. Incorrect
    pointer was being tested for NULL. Bug introduced by commit fbcf62a3
    (mtd: physmap_of: move parse_obsolete_partitions to become separate
    parser).
    This patch fixes this bug.
    
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: Artem Bityutskiy <artem.bityutskiy@intel.com>
    Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8c460f04c9ed2c0089b6e97223cd22653aaf8f0
Author: Andre Przywara <andre.przywara@amd.com>
Date:   Wed Oct 31 17:20:50 2012 +0100

    x86, amd: Disable way access filter on Piledriver CPUs
    
    commit 2bbf0a1427c377350f001fbc6260995334739ad7 upstream.
    
    The Way Access Filter in recent AMD CPUs may hurt the performance of
    some workloads, caused by aliasing issues in the L1 cache.
    This patch disables it on the affected CPUs.
    
    The issue is similar to that one of last year:
    http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
    This new patch does not replace the old one, we just need another
    quirk for newer CPUs.
    
    The performance penalty without the patch depends on the
    circumstances, but is a bit less than the last year's 3%.
    
    The workloads affected would be those that access code from the same
    physical page under different virtual addresses, so different
    processes using the same libraries with ASLR or multiple instances of
    PIE-binaries. The code needs to be accessed simultaneously from both
    cores of the same compute unit.
    
    More details can be found here:
    http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf
    
    CPUs affected are anything with the core known as Piledriver.
    That includes the new parts of the AMD A-Series (aka Trinity) and the
    just released new CPUs of the FX-Series (aka Vishera).
    The model numbering is a bit odd here: FX CPUs have model 2,
    A-Series has model 10h, with possible extensions to 1Fh. Hence the
    range of model ids.
    
    Signed-off-by: Andre Przywara <osp@andrep.de>
    Link: http://lkml.kernel.org/r/1351700450-9277-1-git-send-email-osp@andrep.de
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2: wrmsrl_safe() is called checking_wrmsrl()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 81ed0cdaaf0d16866ee4f92a520cc261928282c8
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Mon Nov 26 16:29:54 2012 -0800

    watchdog: using u64 in get_sample_period()
    
    commit 8ffeb9b0e6369135bf03a073514f571ef10606b9 upstream.
    
    In get_sample_period(), unsigned long is not enough:
    
      watchdog_thresh * 2 * (NSEC_PER_SEC / 5)
    
    case1:
      watchdog_thresh is 10 by default, the sample value will be: 0xEE6B2800
    
    case2:
     set watchdog_thresh is 20, the sample value will be: 0x1 DCD6 5000
    
    In case2, we need use u64 to express the sample period.  Otherwise,
    changing the threshold thru proc often can not be successful.
    
    Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
    Acked-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a126b90084c5948bb0cec91d46442dc90326c4eb
Author: Jussi Pakkanen <jussi.pakkanen@canonical.com>
Date:   Tue Jan 10 23:04:16 2012 -0800

    Input: bcm5974 - set BUTTONPAD property
    
    commit 52965cc012f7a3cf35f06485ec275ebf3b3fddae upstream.
    
    Some bcm5974 trackpads have a physical button beneath the physical surface.
    This patch sets the property bit so user space applications can detect the
    trackpad type and act accordingly.
    
    Signed-off-by: Jussi Pakkanen <jussi.pakkanen@canonical.com>
    Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 08151fae3f717f0c0c2064bbfd2799be398edac7
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Fri Nov 4 13:31:23 2011 -0700

    x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
    
    commit 29e9bf1841e4f9df13b4992a716fece7087dd237 upstream.
    
    Thermal throttle and power limit events are not defined as MCE errors in x86
    architecture and should not generate MCE errors in mcelog.
    
    Current kernel generates fake software defined MCE errors for these events.
    This may confuse users because they may think the machine has real MCE errors
    while actually only thermal throttle or power limit events happen.
    
    To make it worse, buggy firmware on some platforms may falsely generate
    the events. Therefore, kernel reports MCE errors which users think as real
    hardware errors. Although the firmware bugs should be fixed, on the other hand,
    kernel should not report MCE errors either.
    
    So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
    package_power_limit_count, core_throttle_count, and package_throttle_count) in
    /sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
    for each event on each CPU. Please note that all CPU's on one package report
    duplicate counters. It's user application's responsibity to retrieve a package
    level counter for one package.
    
    This patch doesn't report package level power limit, core level power limit, and
    package level thermal throttle events in mcelog. When the events happen, only
    report them in respective counters in sysfs.
    
    Since core level thermal throttle has been legacy code in kernel for a while and
    users accepted it as MCE error in mcelog, core level thermal throttle is still
    reported in mcelog. In the mean time, the event is counted in a counter in sysfs
    as well.
    
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Acked-by: Borislav Petkov <bp@amd64.org>
    Acked-by: Tony Luck <tony.luck@intel.com>
    Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41edb6f95d83485b473d575778b815dc13edee3c
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue Oct 25 13:55:30 2011 +0200

    xhci: Remove scary warnings about transfer issues.
    
    commit 2a9227a5eeaeb3f91e3a72ceea4fa59016ca5d20 upstream.
    
    Getting a short packet or a babble error is usually a recoverable error,
    so stop scaring users with warnings in dmesg when xHCI debugging is turned
    off.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bf40c0c37d10920e31efa84cad2a4c74a4ecedc5
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Dec 22 15:02:13 2011 -0800

    xhci: Remove warnings about MSI and MSI-X capabilities.
    
    commit 3b9783b277e66731891ab42eeaacebbdcdd6e629 upstream.
    
    xHCI host controllers may not be capable of MSI, but they should be able
    to be used in legacy PCI interrupt mode.  Similarly, some xHCI host
    controllers will have MSI support but not MSI-X support.  Lower the
    dmesg log level from an error to debug.  The message won't appear unless
    CONFIG_USB_XHCI_HCD_DEBUGGING is turned on.
    
    If we need to find out whether the device can support MSI or MSI-X and
    it's not being enabled by the driver, it's easy to ask the user to run
    lspci.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit adb8fc74bda5be948291066422d44916f7f89e2d
Author: Merlin Schumacher <merlin.schumacher@gmail.com>
Date:   Tue Jan 24 04:35:35 2012 +0800

    acer-wmi: support for P key on TM8372
    
    commit 67e1d34cd54cbf33f093f1dd53e7bda1124eb972 upstream.
    
    BugLink: http://launchpad.net/bugs/865807
    
    There is no entry for P key on TM8372, so when P key is pressed, only
    "acer_wmi: Unknown key number - 0x29" in dmesg.
    
    Signed-off-by: Merlin Schumacher <merlin.schumacher@gmail.com>
    Signed-off-by: Ike Panhc <ike.pan@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e17e8e6a1846d94511b5c15fdfe3f1f1aba7d2ff
Author: Seth Heasley <seth.heasley@intel.com>
Date:   Mon Jan 23 16:40:55 2012 -0800

    watchdog: iTCO_wdt: add Intel Lynx Point DeviceIDs
    
    commit 84e83c2846ffb42772056a0f825d8578dc92d586 upstream.
    
    This patch adds the TCO Watchdog DeviceIDs for the Intel Lynx Point PCH.
    
    Signed-off-by: Seth Heasley <seth.heasley@intel.com>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit deb4856fc4353f1510dff0628d9c98f84709733d
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Thu Nov 1 12:30:16 2012 +0000

    ptp: update adjfreq callback description
    
    commit 87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99 upstream.
    
    This patch updates the adjfreq callback description to include a note that the
    delta in ppb is always relative to the base frequency, and not to the current
    frequency of the hardware clock.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    CC: Richard Cochran <richard.cochran@gmail.com>
    CC: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 23da2a1f5e79c95dbae9c88848b57e39af80b326
Author: Benjamin Marzinski <bmarzins@redhat.com>
Date:   Wed Nov 7 00:38:06 2012 -0600

    GFS2: Test bufdata with buffer locked and gfs2_log_lock held
    
    commit 96e5d1d3adf56f1c7eeb07258f6a1a0a7ae9c489 upstream.
    
    In gfs2_trans_add_bh(), gfs2 was testing if a there was a bd attached to the
    buffer without having the gfs2_log_lock held. It was then assuming it would
    stay attached for the rest of the function. However, without either the log
    lock being held of the buffer locked, __gfs2_ail_flush() could detach bd at any
    time.  This patch moves the locking before the test.  If there isn't a bd
    already attached, gfs2 can safely allocate one and attach it before locking.
    There is no way that the newly allocated bd could be on the ail list,
    and thus no way for __gfs2_ail_flush() to detach it.
    
    Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9ca6025acefa787bf57ac748fbd987fd79e2d259
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Oct 24 08:44:32 2012 +0000

    bas_gigaset: fix pre_reset handling
    
    commit c6fdd8e5d0c65bb8821dc6da26ee1a2ddd58b3cc upstream.
    
    The delayed work function int_in_work() may call usb_reset_device()
    and thus, indirectly, the driver's pre_reset method. Trying to
    cancel the work synchronously in that situation would deadlock.
    Fix by avoiding cancel_work_sync() in the pre_reset method.
    
    If the reset was NOT initiated by int_in_work() this might cause
    int_in_work() to run after the post_reset method, with urb_int_in
    already resubmitted, so handle that case gracefully.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a30fc5988dd488e280fe8d3eb636e6fba00af139
Author: Arend van Spriel <arend@broadcom.com>
Date:   Thu Feb 23 18:38:23 2012 +0100

    brcm80211: smac: only print block-ack timeout message at trace level
    
    commit 2b0a53d51b5f263bb581bbdb40ebb9f7e09609b1 upstream.
    
    In regular use block-ack timeouts can happen so it does not make
    sense to fill the log with these messages.
    
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Reviewed-by: Alwin Beukers <alwin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e0ba0daed156278391f22f92575f4e8fdd41927
Author: Marek Vasut <marex@denx.de>
Date:   Sun Aug 5 23:57:15 2012 +0200

    HID: add quirk for Freescale i.MX28 ROM recovery
    
    commit 2843b673d03421e0e73cf061820d1db328f7c8eb upstream.
    
    The USB recovery mode present in i.MX28 ROM emulates USB HID.
    It needs this quirk to behave properly.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Chen Peter <B29397@freescale.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    [jkosina@suse.cz: fix alphabetical ordering]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fe16e58bbb29ec4a7893dc86da3b818005c0ff40
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Sat Nov 17 22:27:04 2012 +0100

    m68k: fix sigset_t accessor functions
    
    commit 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.
    
    The sigaddset/sigdelset/sigismember functions that are implemented with
    bitfield insn cannot allow the sigset argument to be placed in a data
    register since the sigset is wider than 32 bits.  Remove the "d"
    constraint from the asm statements.
    
    The effect of the bug is that sending RT signals does not work, the signal
    number is truncated modulo 32.
    
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d59e26fe9008e2382af445ed590446983614dfa
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Fri Sep 28 16:16:00 2012 -0300

    get_dvb_firmware: fix download site for tda10046 firmware
    
    commit 25ec43d3e6306978cf66060ed18c4160ce8fc302 upstream.
    
    The previous website doesn't exist anymore. Update it to one site that
    actually exists.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 48eabc148c7637812a6de645a1b6ca07ff0bf91f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 20 13:07:05 2012 +0100

    drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
    
    commit b03543857fd75876b96e10d4320b775e95041bb7 upstream.
    
    Currently i915 driver checks [PCH_]LVDS register bits to decide
    whether to set up the dual-link or the single-link mode.  This relies
    implicitly on that BIOS initializes the register properly at boot.
    However, BIOS doesn't initialize it always.  When the machine is
    booted with the closed lid, BIOS skips the LVDS reg initialization.
    This ends up in blank output on a machine with a dual-link LVDS when
    you open the lid after the boot.
    
    This patch adds a workaround for that problem by checking the initial
    LVDS register value in VBT.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37742
    Tested-By: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b1d52b72b5f597dfcb54e26c688b8e05b77f593f
Author: joshua.a.hay@intel.com <joshua.a.hay@intel.com>
Date:   Fri Sep 21 00:08:21 2012 +0000

    ixgbe: add support for X540-AT1
    
    commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.
    
    This patch adds device support for Ethernet Controller X540-AT1.
    
    Signed-off-by: Josh Hay <joshua.a.hay@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 71da5decb10eaed227e6762448d17f9697457035
Author: Emil Tantilov <emil.s.tantilov@intel.com>
Date:   Fri Nov 4 06:43:29 2011 +0000

    ixgbe: add support for new 82599 device id
    
    commit 9e791e4a04c08868f02cd579a428a7268492e1b4 upstream.
    
    Support for new 82599 based quad port adapter.
    
    Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
    Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c01751fb136fa85b8be135ef36440bda699a299f
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sat Oct 29 12:37:06 2011 -0700

    Input: i8042 - also perform controller reset when suspending
    
    commit 1729ad1f4f9e167ade84ca8b5269695c42351160 upstream.
    
    In addition to some laptops needing i8042 reset after resuming from S2R to
    get their touchpads working there is another class of laptops - ones that
    need i8042 reset before going to S2R, otherwise they will simply reboot
    instead of resuming.
    
    See https://bugzilla.kernel.org/show_bug.cgi?id=15612
    
    This change forces reset of i8042 before doing S2R.
    
    Reported-by: Stefan Koch <stefan_koch@gmx.net>
    Tested-by: Alexander van Loon <a.vanloon@alexandervanloon.nl>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ebe02a7b9e68501ef9a0dc9b04f3370c056b896e
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Sat Jan 21 02:08:17 2012 -0800

    PCI : Calculate right add_size
    
    commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream.
    
    During debug of one SRIOV enabled hotplug device, we found found that
    add_size is not passed properly.
    
    The device has devices under two level bridges:
    
     +-[0000:80]-+-00.0-[81-8f]--
     |           +-01.0-[90-9f]--
     |           +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0  Oracle Corporation Device
     |           |                               \-03.0-[a3]--+-00.0  Oracle Corporation Device
    
    Which means later the parent bridge will not try to add a big enough range:
    
    [  557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff]
    [  557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref]
    [  557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff]
    [  557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref]
    [  557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff]
    [  557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref]
    [  557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000)
    [  557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff]
    [  557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000)
    [  557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]
    
    It turns out we did not calculate size1 properly.
    
    static resource_size_t calculate_memsize(resource_size_t size,
                    resource_size_t min_size,
                    resource_size_t size1,
                    resource_size_t old_size,
                    resource_size_t align)
    {
            if (size < min_size)
                    size = min_size;
            if (old_size == 1 )
                    old_size = 0;
            if (size < old_size)
                    size = old_size;
            size = ALIGN(size + size1, align);
            return size;
    }
    
    We should not pass add_size with min_size in calculate_memsize since
    that will make add_size not contribute final add_size.
    
    So just pass add_size with size1 to calculate_memsize().
    
    With this change, we should have chance to remove extra addon in
    pci_reassign_resource.
    
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9dfbb96d0323de990ade388c566e14db9837636
Author: Jan Safrata <jan.nikitenko@gmail.com>
Date:   Tue May 22 14:04:50 2012 +0200

    usb: use usb_serial_put in usb_serial_probe errors
    
    commit 0658a3366db7e27fa32c12e886230bb58c414c92 upstream.
    
    The use of kfree(serial) in error cases of usb_serial_probe
    was invalid - usb_serial structure allocated in create_serial()
    gets reference of usb_device that needs to be put, so we need
    to use usb_serial_put() instead of simple kfree().
    
    Signed-off-by: Jan Safrata <jan.nikitenko@gmail.com>
    Acked-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4affc3ac58e26b9ed85ce7d30f1f58975dd157cd
Author: Tom Herbert <therbert@google.com>
Date:   Fri Nov 16 09:04:15 2012 +0000

    net-rps: Fix brokeness causing OOO packets
    
    [ Upstream commit baefa31db2f2b13a05d1b81bdf2d20d487f58b0a ]
    
    In commit c445477d74ab3779 which adds aRFS to the kernel, the CPU
    selected for RFS is not set correctly when CPU is changing.
    This is causing OOO packets and probably other issues.
    
    Signed-off-by: Tom Herbert <therbert@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ff5d468a3f897811682442ae2a0e6b303679d8a6
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Wed Nov 14 02:51:04 2012 +0000

    net: correct check in dev_addr_del()
    
    [ Upstream commit a652208e0b52c190e57f2a075ffb5e897fe31c3b ]
    
    Check (ha->addr == dev->dev_addr) is always true because dev_addr_init()
    sets this. Correct the check to behave properly on addr removal.
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit edd265dc3128ce255654440b6bdf518dbe6325fd
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Sat Nov 10 19:52:34 2012 +0000

    ipv6: setsockopt(IPIPPROTO_IPV6, IPV6_MINHOPCOUNT) forgot to set return value
    
    [ Upstream commit d4596bad2a713fcd0def492b1960e6d899d5baa8 ]
    
    Cc: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58fda05f80418cf457e3425d8b58b15262198398
Author: Xi Wang <xi.wang@gmail.com>
Date:   Sun Nov 11 11:20:01 2012 +0000

    ipv4: avoid undefined behavior in do_ip_setsockopt()
    
    [ Upstream commit 0c9f79be295c99ac7e4b569ca493d75fdcc19e4e ]
    
    (1<<optname) is undefined behavior in C with a negative optname or
    optname larger than 31.  In those cases the result of the shift is
    not necessarily zero (e.g., on x86).
    
    This patch simplifies the code with a switch statement on optname.
    It also allows the compiler to generate better code (e.g., using a
    64-bit mask).
    
    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c1972f1b4f784560003075e05dcd95c1db8116e
Author: Ulrich Weber <ulrich.weber@sophos.com>
Date:   Thu Oct 25 05:34:45 2012 +0000

    netfilter: nf_nat: don't check for port change on ICMP tuples
    
    commit 38fe36a248ec3228f8e6507955d7ceb0432d2000 upstream.
    
    ICMP tuples have id in src and type/code in dst.
    So comparing src.u.all with dst.u.all will always fail here
    and ip_xfrm_me_harder() is called for every ICMP packet,
    even if there was no NAT.
    
    Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
    [Pablo Neira Ayuso: Backported to.3.0]
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58fd4b237523afd2a925ccc664d35f0334da4ffd
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Fri Aug 31 09:55:54 2012 +0000

    netfilter: Validate the sequence number of dataless ACK packets as well
    
    commit 4a70bbfaef0361d27272629d1a250a937edcafe4 upstream.
    
    We spare nothing by not validating the sequence number of dataless
    ACK packets and enabling it makes harder off-path attacks.
    
    See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,
    http://arxiv.org/abs/1201.2074
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b5ce3e0d724f18d39ca996164baef3011ff3c409
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Fri Aug 31 09:55:53 2012 +0000

    netfilter: Mark SYN/ACK packets as invalid from original direction
    
    commit 64f509ce71b08d037998e93dd51180c19b2f464c upstream.
    
    Clients should not send such packets. By accepting them, we open
    up a hole by wich ephemeral ports can be discovered in an off-path
    attack.
    
    See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,
    http://arxiv.org/abs/1201.2074
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c8a84725562375ddd0b86671012292704bdc2419
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Oct 25 15:45:26 2012 -0700

    x86, mm: Undo incorrect revert in arch/x86/mm/init.c
    
    commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.
    
    Commit
    
        844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped
    
    added back some lines back wrongly that has been removed in commit
    
        7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"
    
    remove them again.
    
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com
    Acked-by: Jacob Shin <jacob.shin@amd.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d7a5b9d13e1681163bc7572d15e2093e3311bc7
Author: Jacob Shin <jacob.shin@amd.com>
Date:   Wed Oct 24 14:24:44 2012 -0500

    x86, mm: Find_early_table_space based on ranges that are actually being mapped
    
    commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream.
    
    Current logic finds enough space for direct mapping page tables from 0
    to end. Instead, we only need to find enough space to cover mr[0].start
    to mr[nr_range].end -- the range that is actually being mapped by
    init_memory_mapping()
    
    This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address
    the panic reported here:
    
      https://lkml.org/lkml/2012/10/20/160
      https://lkml.org/lkml/2012/10/21/157
    
    Signed-off-by: Jacob Shin <jacob.shin@amd.com>
    Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie
    Tested-by: Tom Rini <trini@ti.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - The log message format is a bit different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3493cfdd799c2be01fe935801fb4c99c14058e58
Author: Jacob Shin <jacob.shin@amd.com>
Date:   Thu Oct 20 16:15:26 2011 -0500

    x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.
    
    commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.
    
    On systems with very large memory (1 TB in our case), BIOS may report a
    reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
    these from the direct mapping.
    
    [ hpa: this should be done not just for > 4 GB but for everything above the legacy
      region (1 MB), at the very least.  That, however, turns out to require significant
      restructuring.  That work is well underway, but is not suitable for rc/stable. ]
    
    Signed-off-by: Jacob Shin <jacob.shin@amd.com>
    Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79be252393312e96afcd0872e6ac0445e7398798
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 16 14:15:04 2012 -0800

    tmpfs: change final i_blocks BUG to WARNING
    
    commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream.
    
    Under a particular load on one machine, I have hit shmem_evict_inode()'s
    BUG_ON(inode->i_blocks), enough times to narrow it down to a particular
    race between swapout and eviction.
    
    It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(),
    and the lack of coherent locking between mapping's nrpages and shmem's
    swapped count.  There's a window in shmem_writepage(), between lowering
    nrpages in shmem_delete_from_page_cache() and then raising swapped
    count, when the freed count appears to be +1 when it should be 0, and
    then the asymmetry stops it from being corrected with -1 before hitting
    the BUG.
    
    One answer is coherent locking: using tree_lock throughout, without
    info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on
    used_blocks makes that messier than expected.  Another answer may be a
    further effort to eliminate the weird shmem_recalc_inode() altogether,
    but previous attempts at that failed.
    
    So far undecided, but for now change the BUG_ON to WARN_ON: in usual
    circumstances it remains a useful consistency check.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a5db678c3b407681a285d2ea7d9460bc956c2e0a
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Nov 16 14:14:49 2012 -0800

    memcg: oom: fix totalpages calculation for memory.swappiness==0
    
    commit 9a5a8f19b43430752067ecaee62fc59e11e88fa6 upstream.
    
    oom_badness() takes a totalpages argument which says how many pages are
    available and it uses it as a base for the score calculation.  The value
    is calculated by mem_cgroup_get_limit which considers both limit and
    total_swap_pages (resp.  memsw portion of it).
    
    This is usually correct but since fe35004fbf9e ("mm: avoid swapping out
    with swappiness==0") we do not swap when swappiness is 0 which means
    that we cannot really use up all the totalpages pages.  This in turn
    confuses oom score calculation if the memcg limit is much smaller than
    the available swap because the used memory (capped by the limit) is
    negligible comparing to totalpages so the resulting score is too small
    if adj!=0 (typically task with CAP_SYS_ADMIN or non zero oom_score_adj).
    A wrong process might be selected as result.
    
    The problem can be worked around by checking mem_cgroup_swappiness==0
    and not considering swap at all in such a case.
    
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d9bf922e7f546cdd8a63d32b743429545c1be60a
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Tue Nov 13 18:31:55 2012 +0000

    ttm: Clear the ttm page allocated from high memory zone correctly
    
    commit ac207ed2471150e06af0afc76e4becc701fa2733 upstream.
    
    The TTM page can be allocated from high memory. In such case it is
    wrong to use the page_address(page) as the virtual address for the high memory
    page.
    
    bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50241
    
    Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ac178309d45286240047ebf1c1bc246b16cd34bc
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Nov 14 09:10:39 2012 -0500

    drm/radeon: fix logic error in atombios_encoders.c
    
    commit b9196395c905edec512dfd6690428084228c16ec upstream.
    
    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=50431
    
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc4c79ba84f02dd22330e5b33aa97dd093f77621
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Nov 8 11:56:53 2012 -0600

    USB: option: add Alcatel X220/X500D USB IDs
    
    commit c0bc3098871dd9b964f6b45ec1e4d70d87811744 upstream.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6bed143fa0997be55e7f8dc9303ee54ec727e1aa
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Nov 8 11:56:42 2012 -0600

    USB: option: add Novatel E362 and Dell Wireless 5800 USB IDs
    
    commit fcb21645f1bd86d2be29baf48aa1b298de52ccc7 upstream.
    
    The Dell 5800 appears to be a simple rebrand of the Novatel E362.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 63d0412fb38ee2f13e7d68b1f2b136ea91d52bc2
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Mon Oct 22 15:49:02 2012 +0200

    s390/gup: add missing TASK_SIZE check to get_user_pages_fast()
    
    commit d55c4c613fc4d4ad2ba0fc6fa2b57176d420f7e4 upstream.
    
    When walking page tables we need to make sure that everything
    is within bounds of the ASCE limit of the task's address space.
    Otherwise we might calculate e.g. a pud pointer which is not
    within a pud and dereference it.
    So check against TASK_SIZE (which is the ASCE limit) before
    walking page tables.
    
    Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a3a3f4a507d46b1c22c923733b172eebcf188f1
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Nov 12 18:31:35 2012 +0200

    drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures
    
    commit d0ddfbd3d1346c1f481ec2289eef350cdba64b42 upstream.
    
    Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
    left behind ghost connectors, attached (with a dangling pointer) to the
    sdvo that has been cleaned up and freed. Properly destroy any connectors
    attached to the encoder.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
    CC: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: bjo@nord-west.org
    [danvet: added a comment to explain why we need to clean up connectors
    even when sdvo_output_setup fails.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbdd5353e2bcb6313f7abd0e0cfbf2854bfc924d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Nov 12 10:51:34 2012 +0100

    wireless: allow 40 MHz on world roaming channels 12/13
    
    commit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream.
    
    When in world roaming mode, allow 40 MHz to be used
    on channels 12 and 13 so that an AP that is, e.g.,
    using HT40+ on channel 9 (in the UK) can be used.
    
    Reported-by: Eddie Chapman <eddie@ehuk.net>
    Tested-by: Eddie Chapman <eddie@ehuk.net>
    Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b6908c5824b42966d700c10a9c4241b5f82119e1
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Wed Nov 7 10:44:08 2012 +0100

    s390/signal: set correct address space control
    
    commit fa968ee215c0ca91e4a9c3a69ac2405aae6e5d2f upstream.
    
    If user space is running in primary mode it can switch to secondary
    or access register mode, this is used e.g. in the clock_gettime code
    of the vdso. If a signal is delivered to the user space process while
    it has been running in access register mode the signal handler is
    executed in access register mode as well which will result in a crash
    most of the time.
    
    Set the address space control bits in the PSW to the default for the
    execution of the signal handler and make sure that the previous
    address space control is restored on signal return. Take care
    that user space can not switch to the kernel address space by
    modifying the registers in the signal frame.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    [bwh: Backported to 3.2:
     - Adjust filename
     - The RI bit is not included in PSW_MASK_USER]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5f7f7869750172ec1af2b3c489bd943db9086a2a
Author: Misael Lopez Cruz <misael.lopez@ti.com>
Date:   Thu Nov 8 12:03:12 2012 -0600

    ASoC: dapm: Use card_list during DAPM shutdown
    
    commit 445632ad6dda42f4d3f9df2569a852ca0d4ea608 upstream.
    
    DAPM shutdown incorrectly uses "list" field of codec struct while
    iterating over probed components (codec_dev_list). "list" field
    refers to codecs registered in the system, "card_list" field is
    used for probed components.
    
    Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
    Signed-off-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c5ee58688baa98bc3a4f6095a1acf6fd7fd9e967
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Nov 6 09:17:37 2012 -0800

    device_cgroup: fix RCU usage
    
    commit 201e72acb2d3821e2de9ce6091e98859c316b29a upstream.
    
    dev_cgroup->exceptions is protected with devcgroup_mutex for writes
    and RCU for reads; however, RCU usage isn't correct.
    
    * dev_exception_clean() doesn't use RCU variant of list_del() and
      kfree().  The function can race with may_access() and may_access()
      may end up dereferencing already freed memory.  Use list_del_rcu()
      and kfree_rcu() instead.
    
    * may_access() may be called only with RCU read locked but doesn't use
      RCU safe traversal over ->exceptions.  Use list_for_each_entry_rcu().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Cc: Aristeu Rozanski <aris@redhat.com>
    Cc: Li Zefan <lizefan@huawei.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Exception list is called whitelist]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3e1fab33b18e2b10581e2e163ee74ec3d040a09a
Author: Eric Millbrandt <emillbrandt@dekaresearch.com>
Date:   Fri Nov 2 17:05:44 2012 -0400

    ASoC: wm8978: pll incorrectly configured when codec is master
    
    commit 55c6f4cb6ef49afbb86222c6a3ff85329199c729 upstream.
    
    When MCLK is supplied externally and BCLK and LRC are configured as outputs
    (codec is master), the PLL values are only calculated correctly on the first
    transmission.  On subsequent transmissions, at differenct sample rates, the
    wrong PLL values are used.  Test for f_opclk instead of f_pllout to determine
    if the PLL values are needed.
    
    Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3686bdea72e26803d29be3e67cd11f18a97b246a
Author: Arik Nemtsov <arik@wizery.com>
Date:   Mon Nov 5 10:27:52 2012 +0200

    mac80211: sync acccess to tx_filtered/ps_tx_buf queues
    
    commit 987c285c2ae2e4e32aca3a9b3252d28171c75711 upstream.
    
    These are accessed without a lock when ending STA PSM. If the
    sta_cleanup timer accesses these lists at the same time, we might crash.
    
    This may fix some mysterious crashes we had during
    ieee80211_sta_ps_deliver_wakeup.
    
    Signed-off-by: Arik Nemtsov <arik@wizery.com>
    Signed-off-by: Ido Yariv <ido@wizery.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 104d7aa3d8c5f948a363c3814e0361e068a8e222
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Oct 23 22:29:38 2012 +0200

    futex: Handle futex_pi OWNER_DIED take over correctly
    
    commit 59fa6245192159ab5e1e17b8e31f15afa9cff4bf upstream.
    
    Siddhesh analyzed a failure in the take over of pi futexes in case the
    owner died and provided a workaround.
    See: http://sourceware.org/bugzilla/show_bug.cgi?id=14076
    
    The detailed problem analysis shows:
    
    Futex F is initialized with PTHREAD_PRIO_INHERIT and
    PTHREAD_MUTEX_ROBUST_NP attributes.
    
    T1 lock_futex_pi(F);
    
    T2 lock_futex_pi(F);
       --> T2 blocks on the futex and creates pi_state which is associated
           to T1.
    
    T1 exits
       --> exit_robust_list() runs
           --> Futex F userspace value TID field is set to 0 and
               FUTEX_OWNER_DIED bit is set.
    
    T3 lock_futex_pi(F);
       --> Succeeds due to the check for F's userspace TID field == 0
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space
    
    T1 --> exit_pi_state_list()
           --> Transfers pi_state to waiter T2 and wakes T2 via
           	   rt_mutex_unlock(&pi_state->mutex)
    
    T2 --> acquires pi_state->mutex and gains real ownership of the
           pi_state
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space
    
    T3 --> observes inconsistent state
    
    This problem is independent of UP/SMP, preemptible/non preemptible
    kernels, or process shared vs. private. The only difference is that
    certain configurations are more likely to expose it.
    
    So as Siddhesh correctly analyzed the following check in
    futex_lock_pi_atomic() is the culprit:
    
    	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
    
    We check the userspace value for a TID value of 0 and take over the
    futex unconditionally if that's true.
    
    AFAICT this check is there as it is correct for a different corner
    case of futexes: the WAITERS bit became stale.
    
    Now the proposed change
    
    -	if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) {
    +       if (unlikely(ownerdied ||
    +                       !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) {
    
    solves the problem, but it's not obvious why and it wreckages the
    "stale WAITERS bit" case.
    
    What happens is, that due to the WAITERS bit being set (T2 is blocked
    on that futex) it enforces T3 to go through lookup_pi_state(), which
    in the above case returns an existing pi_state and therefor forces T3
    to legitimately fight with T2 over the ownership of the pi_state (via
    pi_state->mutex). Probelm solved!
    
    Though that does not work for the "WAITERS bit is stale" problem
    because if lookup_pi_state() does not find existing pi_state it
    returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to
    return -ESRCH to user space because the OWNER_DIED bit is not set.
    
    Now there is a different solution to that problem. Do not look at the
    user space value at all and enforce a lookup of possibly available
    pi_state. If pi_state can be found, then the new incoming locker T3
    blocks on that pi_state and legitimately races with T2 to acquire the
    rt_mutex and the pi_state and therefor the proper ownership of the
    user space futex.
    
    lookup_pi_state() has the correct order of checks. It first tries to
    find a pi_state associated with the user space futex and only if that
    fails it checks for futex TID value = 0. If no pi_state is available
    nothing can create new state at that point because this happens with
    the hash bucket lock held.
    
    So the above scenario changes to:
    
    T1 lock_futex_pi(F);
    
    T2 lock_futex_pi(F);
       --> T2 blocks on the futex and creates pi_state which is associated
           to T1.
    
    T1 exits
       --> exit_robust_list() runs
           --> Futex F userspace value TID field is set to 0 and
               FUTEX_OWNER_DIED bit is set.
    
    T3 lock_futex_pi(F);
       --> Finds pi_state and blocks on pi_state->rt_mutex
    
    T1 --> exit_pi_state_list()
           --> Transfers pi_state to waiter T2 and wakes it via
           	   rt_mutex_unlock(&pi_state->mutex)
    
    T2 --> acquires pi_state->mutex and gains ownership of the pi_state
       --> Claims ownership of the futex and sets its own TID into the
           userspace TID field of futex F
       --> returns to user space
    
    This covers all gazillion points on which T3 might come in between
    T1's exit_robust_list() clearing the TID field and T2 fixing it up. It
    also solves the "WAITERS bit stale" problem by forcing the take over.
    
    Another benefit of changing the code this way is that it makes it less
    dependent on untrusted user space values and therefor minimizes the
    possible wreckage which might be inflicted.
    
    As usual after staring for too long at the futex code my brain hurts
    so much that I really want to ditch that whole optimization of
    avoiding the syscall for the non contended case for PI futexes and rip
    out the maze of corner case handling code. Unfortunately we can't as
    user space relies on that existing behaviour, but at least thinking
    about it helps me to preserve my mental sanity. Maybe we should
    nevertheless :)
    
    Reported-and-tested-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1210232138540.2756@ionos
    Acked-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c26a0f67479f10d0241a79c306eb1b9002e98d51
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Tue Oct 9 16:20:15 2012 +0300

    UBIFS: fix mounting problems after power cuts
    
    commit a28ad42a4a0c6f302f488f26488b8b37c9b30024 upstream.
    
    This is a bugfix for a problem with the following symptoms:
    
    1. A power cut happens
    2. After reboot, we try to mount UBIFS
    3. Mount fails with "No space left on device" error message
    
    UBIFS complains like this:
    
    UBIFS error (pid 28225): grab_empty_leb: could not find an empty LEB
    
    The root cause of this problem is that when we mount, not all LEBs are
    categorized. Only those which were read are. However, the
    'ubifs_find_free_leb_for_idx()' function assumes that all LEBs were
    categorized and 'c->freeable_cnt' is valid, which is a false assumption.
    
    This patch fixes the problem by teaching 'ubifs_find_free_leb_for_idx()'
    to always fall back to LPT scanning if no freeable LEBs were found.
    
    This problem was reported by few people in the past, but Brent Taylor
    was able to reproduce it and send me a flash image which cannot be mounted,
    which made it easy to hunt the bug. Kudos to Brent.
    
    Reported-by: Brent Taylor <motobud@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fd132e0440dfad94d4cda744377c81da474d53b9
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Wed Oct 10 10:55:28 2012 +0300

    UBIFS: introduce categorized lprops counter
    
    commit 98a1eebda3cb2a84ecf1f219bb3a95769033d1bf upstream.
    
    This commit is a preparation for a subsequent bugfix. We introduce a
    counter for categorized lprops.
    
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>