commit dbf932a9b316d5b29b3e220e5a30e7a165ad2992
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 11 13:57:46 2013 -0700

    Linux 3.8.13

commit 34660a13cda790e62bac8229b15317007cea247a
Author: Jerry Hoemann <jerry.hoemann@hp.com>
Date:   Tue Apr 30 15:15:55 2013 -0600

    x86/mm: account for PGDIR_SIZE alignment
    
    Patch for -stable.  Function find_early_table_space removed upstream.
    
    Fixes panic in alloc_low_page due to pgt_buf overflow during
    init_memory_mapping.
    
    find_early_table_space sizes pgt_buf based upon the size of the
    memory being mapped, but it does not take into account the alignment
    of the memory.  When the region being mapped spans a 512GB (PGDIR_SIZE)
    alignment, a panic from alloc_low_pages occurs.
    
    kernel_physical_mapping_init takes into account PGDIR_SIZE alignment.
    This causes an extra call to alloc_low_page to be made.  This extra call
    isn't accounted for by find_early_table_space and causes a kernel panic.
    
    Change is to take into account PGDIR_SIZE alignment in find_early_table_space.
    
    Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fccd6eb97dab4cf45b2cda8278d5a7582cd40d08
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon Apr 29 15:05:19 2013 -0700

    kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
    
    commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream.
    
    audit_trim_trees() calls get_tree().  If a failure occurs we must call
    put_tree().
    
    [akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement]
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76e7f478a400a76a37a05848cc2e9263e0d0cb40
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Apr 30 12:43:42 2013 -0400

    NFSv4.x: Fix handling of partially delegated locks
    
    commit c5a2a15f8146fdfe45078df7873a6dc1006b3869 upstream.
    
    If a NFS client receives a delegation for a file after it has taken
    a lock on that file, we can currently end up in a situation where
    we mistakenly skip unlocking that file.
    
    The following patch swaps an erroneous check in nfs4_proc_unlck for
    whether or not the file has a delegation to one which checks whether
    or not we hold a lock stateid for that file.
    
    Reported-by: Chuck Lever <Chuck.Lever@oracle.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Chuck Lever <Chuck.Lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a3f1f30a22ab33f948f0c4a6d56fc7cc5df5199
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Tue Apr 30 15:17:16 2013 +0530

    EDAC: Don't give write permission to read-only files
    
    commit c8c64d165ccfd2274058ac84e0c680f9b48c4ec1 upstream.
    
    I get the following warning on boot:
    
    ------------[ cut here ]------------
    WARNING: at drivers/base/core.c:575 device_create_file+0x9a/0xa0()
    Hardware name:  -[8737R2A]-
    Write permission without 'store'
    ...
    </snip>
    
    Drilling down, this is related to dynamic channel ce_count attribute
    files sporting a S_IWUSR mode without a ->store() function. Looking
    around, it appears that they aren't supposed to have a ->store()
    function. So remove the bogus write permission to get rid of the
    warning.
    
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
    [ shorten commit message ]
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c665070565cc75380d09c4a94142781191e8c22e
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Wed Apr 24 16:32:55 2013 -0400

    Btrfs: fix extent logging with O_DIRECT into prealloc
    
    commit eb384b55ae9c2055ea00c5cc87971e182d47aefa upstream.
    
    This is the same as the fix from commit
    
    Btrfs: fix bad extent logging
    
    but for O_DIRECT.  I missed this when I fixed the problem originally, we were
    still using the em for the orig_start and orig_block_len, which would be the
    merged extent.  We need to use the actual extent from the on disk file extent
    item, which we have to lookup to make sure it's ok to nocow anyway so just pass
    in some pointers to hold this info.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02cfa2ab3ec610411e30dd15b1df2df0e31afde7
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Mon Apr 1 20:36:28 2013 -0400

    Btrfs: compare relevant parts of delayed tree refs
    
    commit 41b0fc42800569f63e029549b75c4c9cb63f2dfd upstream.
    
    A user reported a panic while running a balance.  What was happening was he was
    relocating a block, which added the reference to the relocation tree.  Then
    relocation would walk through the relocation tree and drop that reference and
    free that block, and then it would walk down a snapshot which referenced the
    same block and add another ref to the block.  The problem is this was all
    happening in the same transaction, so the parent block was free'ed up when we
    drop our reference which was immediately available for allocation, and then it
    was used _again_ to add a reference for the same block from a different
    snapshot.  This resulted in something like this in the delayed ref tree
    
    add ref to 90234880, parent=2067398656, ref_root 1766, level 1
    del ref to 90234880, parent=2067398656, ref_root 18446744073709551608, level 1
    add ref to 90234880, parent=2067398656, ref_root 1767, level 1
    
    as you can see the ref_root's don't match, because when we inc the ref we use
    the header owner, which is the original tree the block belonged to, instead of
    the data reloc tree.  Then when we remove the extent we use the reloc tree
    objectid.  But none of this matters, since it is a shared reference which means
    only the parent matters.  When the delayed ref stuff runs it adds all the
    increments first, and then does all the drops, to make sure that we don't delete
    the ref if we net a positive ref count.  But tree blocks aren't allowed to have
    multiple refs from the same block, so this panics when it tries to add the
    second ref.  We need the add and the drop to cancel each other out in memory so
    we only do the final add.
    
    So to fix this we need to adjust how the delayed refs are added to the tree.
    Only the ref_root matters when it is a normal backref, and only the parent
    matters when it is a shared backref.  So make our decision based on what ref
    type we have.  This allows us to keep the ref_root in memory in case anybody
    wants to use it for something else, and it allows the delayed refs to be merged
    properly so we don't end up with this panic.
    
    With this patch the users image no longer panics on mount, and it has a clean
    fsck after a normal mount/umount cycle.  Thanks,
    
    Reported-by: Roman Mamedov <rm@romanrm.ru>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbc666f0002eb6c97609e59af39fca010ecf8ddd
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Fri Mar 15 13:10:35 2013 -0400

    tracing: Fix ftrace_dump()
    
    commit 7fe70b579c9e3daba71635e31b6189394e7b79d3 upstream.
    
    ftrace_dump() had a lot of issues. What ftrace_dump() does, is when
    ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it
    will dump out the ftrace buffers to the console when either a oops,
    panic, or a sysrq-z occurs.
    
    This was written a long time ago when ftrace was fragile to recursion.
    But it wasn't written well even for that.
    
    There's a possible deadlock that can occur if a ftrace_dump() is happening
    and an NMI triggers another dump. This is because it grabs a lock
    before checking if the dump ran.
    
    It also totally disables ftrace, and tracing for no good reasons.
    
    As the ring_buffer now checks if it is read via a oops or NMI, where
    there's a chance that the buffer gets corrupted, it will disable
    itself. No need to have ftrace_dump() do the same.
    
    ftrace_dump() is now cleaned up where it uses an atomic counter to
    make sure only one dump happens at a time. A simple atomic_inc_return()
    is enough that is needed for both other CPUs and NMIs. No need for
    a spinlock, as if one CPU is running the dump, no other CPU needs
    to do it too.
    
    The tracing_on variable is turned off and not turned on. The original
    code did this, but it wasn't pretty. By just disabling this variable
    we get the result of not seeing traces that happen between crashes.
    
    For sysrq-z, it doesn't get turned on, but the user can always write
    a '1' to the tracing_on file. If they are using sysrq-z, then they should
    know about tracing_on.
    
    The new code is much easier to read and less error prone. No more
    deadlock possibility when an NMI triggers here.
    
    Reported-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7a0a30e6fcba4c014fedfdb56e19837f8030ea9
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 1 14:34:54 2013 -0400

    drm/radeon: fix handling of v6 power tables
    
    commit 441e76ca83ac604eaf0f046def96d8e3a27eea28 upstream.
    
    The code was mis-handling variable sized arrays.
    
    Reported-by: Sylvain BERTRAND <sylware@legeek.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c9a03e19d6414c7c6f482d8130c7592cbd0ef6a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 25 14:06:05 2013 -0400

    drm/radeon: add new richland pci ids
    
    commit 62d1f92e06aef9665d71ca7e986b3047ecf0b3c7 upstream.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2444704cc6b3135247ee3533e6e04c562141afd
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 25 09:29:17 2013 -0400

    drm/radeon: fix possible segfault when parsing pm tables
    
    commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream.
    
    If we have a empty power table, bail early and allocate
    the default power state.
    
    Should fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=63865
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67d3fdc21b2875d89eb32ec64265d17b9292ff47
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 24 14:39:31 2013 -0400

    drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
    
    commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream.
    
    Reviwed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81f9eaffece244b74f1d0a25218b6d2ab5809638
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 17 09:35:39 2013 -0400

    drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)
    
    commit e884fc640ccbdb6f94b9bdb57cfb8464b6688f4c upstream.
    
    Just disabling the mem requests should be enough, but
    that doesn't seem to work correctly on efi systems.
    
    v2: blank displays first, then disable.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a0efa7ea15f619003b9ac58f9c2313bd98282dd
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Apr 16 12:20:15 2013 -0400

    drm/radeon: Always flush the VM
    
    commit 466476dfdcafbb4286ffa232a3a792731b9dc852 upstream.
    
    This is slightly cleaned up version of Jerome's patch.
    There seems to be an issue tracking the last flush of
    the VM which results in hangs in certain cases when
    VM is used.  For now just flush the VM for every IB.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=62959
    https://bugs.freedesktop.org/show_bug.cgi?id=62997
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f932e0c605d7349d3cf3036d509b5837e4b6861
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 18 16:26:36 2013 -0400

    drm/radeon: fix typo in si_select_se_sh()
    
    commit 79b52d6a7085a3e430c6de450a5847fdbe04159b upstream.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cf84ffff78f75ef364853d29e671402a4d1efae
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 18 09:36:42 2013 -0400

    drm/radeon: fix hdmi mode enable on RS600/RS690/RS740
    
    commit dcb852905772416e322536ced5cb3c796d176af5 upstream.
    
    These chips were previously skipped since they are
    pre-R600.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b441ba2cf1d50f57cb68d26d3303cb695df0f66
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Apr 12 19:15:52 2013 -0400

    drm/radeon: cleanup properly if mmio mapping fails
    
    commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream.
    
    If we fail to map the mmio BAR, skip driver tear down
    that requires mmio.
    
    Should fix:
    https://bugzilla.kernel.org/show_bug.cgi?id=56541
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92f3345933a597abab9112d0127c29b9f4535b9a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 11 12:45:34 2013 -0400

    drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS
    
    commit 2e97be73e5f74a317232740ae82eb8f95326a660 upstream.
    
    Avoids potential interrupt storms when the display is disabled.
    
    May fix:
    https://bugzilla.kernel.org/show_bug.cgi?id=56041
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49b4bf2625c2cec64f1277436b36cc7cd546b174
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 25 13:55:15 2013 -0400

    drm/radeon: add some new SI PCI ids
    
    commit 18932a28419596bc9403770f5d8a108c5433fe59 upstream.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c0050b0d778d326be83d5f57dcaa2af98810eff
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 10 19:08:14 2013 -0400

    drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)
    
    commit abf1457bbbe4c62066bd03c6d31837dea28644dc upstream.
    
    Just disabling the mem requests should be enough, but
    that doesn't seem to work correctly on efi systems.
    
    May fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=57567
    https://bugs.freedesktop.org/show_bug.cgi?id=43655
    https://bugzilla.kernel.org/show_bug.cgi?id=56441
    
    v2: blank displays first, then disable.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f404959ea072d99e46557bd197ff7b01d3ec718d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Apr 9 18:32:01 2013 -0400

    drm/radeon: update wait_for_vblank for r1xx-r4xx
    
    commit 2b48b968c0d00aa5ab520b65a15a4f374cda7dda upstream.
    
    Properly wait for the next vblank region.  The previous
    code didn't always wait long enough depending on the timing.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b38b76076dc96dc76b85e57e116867ee4dc62432
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 10 09:47:05 2013 -0400

    drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx
    
    commit 2f86e2ede39a98650c2d465857405ef1c51372b1 upstream.
    
    Need to wait for the new addresses to take affect before
    re-enabling the MC.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 609326a6060f71626cab7b4bc02b419e42c11f8d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Apr 10 09:58:42 2013 -0400

    drm/radeon: properly lock disp in mc_stop/resume for evergreen+
    
    commit 968c01664ccbe0e46c19a1af662c4c266a904203 upstream.
    
    Need to wait for the new addresses to take affect before
    re-enabling the MC.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 415c4bfb8b5e2a6bdc98f1038d87d2f6393bb216
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Apr 9 18:49:59 2013 -0400

    drm/radeon: update wait_for_vblank for evergreen+
    
    commit 10257a6d8359c41407eb26b7ad7bf710a7e00155 upstream.
    
    Properly wait for the next vblank region.  The previous
    code didn't always wait long enough depending on the timing.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ea646f51598f297ca8a68d546a383c003f002ed
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Apr 9 18:41:15 2013 -0400

    drm/radeon: update wait_for_vblank for r5xx-r7xx
    
    commit bea5497bfc1067620c8c8e9d37a42e0bb6d7d7fa upstream.
    
    Properly wait for the next vblank region.  The previous
    code didn't always wait long enough depending on the timing.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e08af0fb303c97a5bd7be70922110c0a983a1d1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Apr 5 10:28:08 2013 -0400

    drm/radeon/dce6: add missing display reg for tiling setup
    
    commit 7c1c7c18fc752b2a1d07597286467ef186312463 upstream.
    
    A new tiling config register for the display blocks was
    added on DCE6.
    
    May fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=62889
    https://bugs.freedesktop.org/show_bug.cgi?id=57919
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01f2c8f8ece71325f2ea56b6397e0ed590fb505b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 4 14:59:35 2013 -0400

    drm/radeon: fix typo in rv515_mc_resume()
    
    commit 367cbe2fec9b57b72605e2ac4cfd4f2fa823a256 upstream.
    
    Doesn't affect anything as the same address gets written
    in both cases.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e7e32bed1ceb3f3055c075bfdede9ec07125b33
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Apr 1 16:06:25 2013 -0400

    drm/radeon: use frac fb div on RS780/RS880
    
    commit 411678288d61ba17afe1f8afed92200be6bbc65d upstream.
    
    Monitors seem to prefer it.  Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=37696
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f78014bfbeaa96d8c5b1180921bdbb0fdd98d0a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 18 17:12:50 2013 -0400

    drm/radeon: don't use get_engine_clock() on APUs
    
    commit bf05d9985111f85ed6922c134567b96eb789283b upstream.
    
    It doesn't work reliably.  Just report back the currently
    selected engine clock.
    
    Partially fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=62493
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93ebd54611790f79e85bb9d75a131e3f5733d20f
Author: David Müller <d.mueller@elsoft.ch>
Date:   Fri Apr 19 10:41:50 2013 +0200

    drm/i915: Fall back to bit banging mode for DVO transmitter detection
    
    commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream.
    
    As discussed in this thread
    http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
    GMBUS based DVO transmitter detection seems to be unreliable which could
    result in an unusable DVO port.
    
    The attached patch fixes this by falling back to bit banging mode for
    the time DVO transmitter detection is in progress.
    
    Signed-off-by: David Müller <d.mueller@elsoft.ch>
    Tested-by: David Müller <d.mueller@elsoft.ch>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f75bb3137659e678ccdfe353f73adb0d7f6cb68
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Apr 12 18:48:43 2013 +0200

    drm/i915: Fixup Oops in the pipe config computation
    
    commit b6c5164d7bf624f3e1b750787ddb983150c5117c upstream.
    
    Yet again our current confusion between doing the modeset globally,
    but only having the new parameters for one crtc at a time.
    
    So that intel_set_mode essentially already does a global modeset:
    intel_modeset_affected_pipes compares the current state with where we
    want to go to (which is carefully set up by intel_crtc_set_config) and
    then goes through the modeset sequence for any crtc which needs
    updating.
    
    Now the issue is that the actual interface with the remaining code
    still only works on one crtc, and so we only pass in one fb and one
    mode. In intel_set_mode we also only compute one intel_crtc_config
    (which should be the one for the crtc we're doing a modeset on).
    
    The reason for that mismatch is twofold:
    - We want to eventually do all modeset as global state changes, so
    it's just infrastructure prep.
    - But even the old semantics can change more than one crtc when you
    e.g. move a connector from crtc A to crtc B, then both crtc A and B
    need to be updated. Usually that means one pipe is disabled and the
    other enabled. This is also the reason why the hack doesn't touch the
    disable_pipes mask.
    
    Now hilarity ensued in our kms config restore paths when we actually
    try to do a modeset on all crtcs: If the first crtc should be off and
    the second should be on, then the call on the first crtc will notice
    that the 2nd one should be switched on and so tries to compute the
    pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
    after all) it only results in tears.
    
    This case is ridiculously easy to hit on gen2/3 where the lvds output
    is restricted to pipe B. Note that before the pipe_config bpp rework
    gen2/3 didn't care really about the fb->depth, so this is a regression
    brought to light with
    
    commit 4e53c2e010e531b4a014692199e978482d471c7e
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Mar 27 00:44:58 2013 +0100
    
        drm/i915: precompute pipe bpp before touching the hw
    
    But apparently Ajax also managed to blow up pch platforms, probably
    with some randomized configs, and pch platforms trip up over the lack
    of an fb even in the old code. So this actually goes back to the first
    introduction of the new modeset restore code in
    
    commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Nov 23 18:16:34 2012 +0100
    
        drm/i915: force restore on lid open
    
    Fix this mess by now by justing shunting all the cool new global
    modeset logic in intel_modeset_affected_pipes.
    
    v2: Improve commit message and clean up all the comments in
    intel_modeset_affected_pipes - since the introduction of the modeset
    restore code they've been a bit outdated.
    
    Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725
    References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html
    Tested-by: Richard Cochran <richardcochran@gmail.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99367f6b937fd2cd0148c933b76ce7b4883d6501
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 12 15:18:38 2013 +0300

    drm/i915: ensure single initialization and cleanup of backlight device
    
    commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.
    
    Backlight cleanup in the eDP connector destroy callback caused the
    backlight device to be removed on some systems that first initialized LVDS
    and then attempted to initialize eDP. Prevent multiple backlight
    initializations, and ensure backlight cleanup is only done once by moving
    it to modeset cleanup.
    
    A small wrinkle is the introduced asymmetry in backlight
    setup/cleanup. This could be solved by adding refcounting, but it seems
    overkill considering that there should only ever be one backlight device.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Tested-by: Peter Verthez <peter.verthez@skynet.be>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12622510457a776e4871e314c99ca1e279f8c399
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Mon Apr 8 15:48:07 2013 -0300

    drm/i915: set CPT FDI RX polarity bits based on VBT
    
    commit 3f704fa2778d3fe45e6529825a5c7a8bcbc686f4 upstream.
    
    Check the VBT to see if the machine has inverted FDI RX polarity on
    CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
    registers.
    
    This should fix some machines that were showing black screens on all
    outputs.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbb83bb7bea7effffbd4097b3b355780e07f273d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Apr 8 14:28:40 2013 +0100

    drm/i915: Use MLC (l3$) for context objects
    
    commit 4615d4c9e27eda42c3e965f208a4b4065841498c upstream.
    
    Enabling context support increases SwapBuffers latency by about 20%
    (measured on an i7-3720qm). We can offset that loss slightly by enabling
    faster caching for the contexts. As they are not backed by any
    particular cache (such as the sampler or render caches) our only option
    is to select the generic mid-level cache. This reduces the latency of
    the swap by about 5%.
    
    Oddly this effect can be observed running smokin-guns on IVB at
    1280x1024:
    Using BLT copies for swaps: 151.67 fps
    Using Render copies for swaps (unpatched):  141.70 fps
    With contexts disabled: 150.23 fps
    With contexts in L3$: 150.77 fps
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Ben Widawsky <ben@bwidawsk.net>
    Cc: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b578b3a82d830e2170d403b1fb29b649e26a48fb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Apr 4 21:31:03 2013 +0100

    drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
    
    commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream.
    
    In order to fully serialize access to the fenced region and the update
    to the fence register we need to take extreme measures on SNB+, and
    manually flush writes to memory prior to writing the fence register in
    conjunction with the memory barriers placed around the register write.
    
    Fixes i-g-t/gem_fence_thrash
    
    v2: Bring a bigger gun
    v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
    v4: Remove changes for working generations.
    v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
    v6: Rewrite comments to ellide forgotten history.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jon Bloomfield <jon.bloomfield@intel.com>
    Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2)
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1501dd0e01575bda28dccc92a1b260abf3d29038
Author: Egbert Eich <eich@suse.de>
Date:   Thu Apr 4 16:04:02 2013 -0400

    drm/i915: Fix SDVO connector and encoder get_hw_state functions
    
    commit 7a7d1fb79fb581553f4830498045de774a9659f8 upstream.
    
    The connector associated with the encoder is considered active when the
    output associtated with this connector is active on the encoder. The
    encoder itself is considered active when either there is an active
    output on  it or the  respective SDVO channel is active.
    Having active outputs when the SDVO channel is inactive seems to be
    inconsistent: such states can be found when intel_modeset_setup_hw_state()
    collects the hardware state set by the BIOS.
    This inconsistency will be fixed in intel_sanitize_crtc()
    (when intel_crtc_update_dpms() is called), this however only happens
    when the encoder is associated with a crtc.
    
    This patch also reverts:
    
         commit bd6946e87a98fea11907b2a47368e13044458a35
         Author: Daniel Vetter <daniel.vetter@ffwll.ch>
         Date:   Tue Apr 2 21:30:34 2013 +0200
    
             drm/i915: Fix sdvo connector get_hw_state function
    
    Signed-off-by: Egbert Eich <eich@suse.de>
    Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c86622fb778dc8b5b7e1dc7b1492541f59b3d1fc
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Wed Apr 3 14:34:11 2013 +0200

    drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
    
    commit 9e9dd0e889c76c786e8f2e164c825c3c06dea30c upstream.
    
    The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
    mini desktop PCs are probably misleading the LVDS detection
    code in intel_lvds_supported. Nothing is connected to the
    LVDS ports in these systems.
    
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1947c19a70d4cc00421a295a3a75f342489c26b5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 2 21:30:34 2013 +0200

    drm/i915: Fix sdvo connector get_hw_state function
    
    commit bd6946e87a98fea11907b2a47368e13044458a35 upstream.
    
    The active output is only the currently selected one, which does not
    imply that it's actually enabled. Since we don't use the sdvo encoder
    side dpms support, we need to check whether the chip-side sdvo port is
    enabled instead.
    
    v2: Fix up Bugzilla links.
    
    v3: Simplify logic a bit (Chris).
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031
    Cc: Egbert Eich <eich@pdx.freedesktop.org>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Tested-by: Egbert Eich <eich@pdx.freedesktop.org> (v2)
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7066b70bb8f147cda6fe039006bafee89128136
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 15 11:32:18 2012 +0000

    drm/i915: Fix detection of base of stolen memory
    
    commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream.
    
    The routine to query the base of stolen memory was using the wrong
    registers and the wrong encodings on virtually every platform.
    
    It was not until the G33 refresh, that a PCI config register was
    introduced that explicitly said where the stolen memory was. Prior to
    865G there was not even a register that said where the end of usable
    low memory was and where the stolen memory began (or ended depending
    upon chipset). Before then, one has to look at the BIOS memory maps to
    find the Top of Memory. Alas that is not exported by arch/x86 and so we
    have to resort to disabling stolen memory on gen2 for the time being.
    
    Then SandyBridge enlarged the PCI register to a full 32-bits and change
    the encoding of the address, so even though we happened to be querying
    the right register, we read the wrong bits and ended up using address 0
    for our stolen data, i.e. notably FBC.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 294b04d109ad9654f0f6608e7963a2f821d784c5
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu May 2 02:40:25 2013 -0400

    drm/ast: deal with bo reserve fail in dirty update path
    
    commit 306373b645d80625335b8e684fa09b14ba460cec upstream.
    
    Port over the mgag200 fix to ast as it suffers the same issue.
    
        On F19 testing, it was noticed we get a lot of errors in dmesg
        about being unable to reserve the buffer when plymouth starts,
        this is due to the buffer being in the process of migrating,
        so it makes sense we can't reserve it.
    
        In order to deal with it, this adds delayed updates for the dirty
        updates, when the bo is unreservable, in the normal console case
        this shouldn't ever happen, its just when plymouth or X is
        pushing the console bo to system memory.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd282737ffe294ec6345338260d0754450cf2a7d
Author: Dave Airlie <airlied@gmail.com>
Date:   Mon Apr 22 09:54:36 2013 +1000

    drm/prime: keep a reference from the handle to exported dma-buf (v6)
    
    commit 219b47339ced80ca580bb6ce7d1636166984afa7 upstream.
    
    Currently we have a problem with this:
    1. i915: create gem object
    2. i915: export gem object to prime
    3. radeon: import gem object
    4. close prime fd
    5. radeon: unref object
    6. i915: unref object
    
    i915 has an imported object reference in its file priv, that isn't
    cleaned up properly until fd close. The reference gets added at step 2,
    but at step 6 we don't have enough info to clean it up.
    
    The solution is to take a reference on the dma-buf when we export it,
    and drop the reference when the gem handle goes away.
    
    So when we export a dma_buf from a gem object, we keep track of it
    with the handle, we take a reference to the dma_buf. When we close
    the handle (i.e. userspace is finished with the buffer), we drop
    the reference to the dma_buf, and it gets collected.
    
    This patch isn't meant to fix any other problem or bikesheds, and it doesn't
    fix any races with other scenarios.
    
    v1.1: move export symbol line back up.
    
    v2: okay I had to do a bit more, as the first patch showed a leak
    on one of my tests, that I found using the dma-buf debugfs support,
    the problem case is exporting a buffer twice with the same handle,
    we'd add another export handle for it unnecessarily, however
    we now fail if we try to export the same object with a different gem handle,
    however I'm not sure if that is a case I want to support, and I've
    gotten the code to WARN_ON if we hit something like that.
    
    v2.1: rebase this patch, write better commit msg.
    v3: cleanup error handling, track import vs export in linked list,
    these two patches were separate previously, but seem to work better
    like this.
    v4: danvet is correct, this code is no longer useful, since the buffer
    better exist, so remove it.
    v5: always take a reference to the dma buf object, import or export.
    (Imre Deak contributed this originally)
    v6: square the circle, remove import vs export tracking now
    that there is no difference
    
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30edf8c3596c5ec66b13c980196794c41e6ad020
Author: Anisse Astier <anisse@astier.eu>
Date:   Wed Apr 24 17:36:01 2013 +0200

    drm/gma500: fix backlight hotkeys behaviour on netbooks
    
    commit e127dc28cc3057575da0216cde85687153ca180f upstream.
    
    Backlight hotkeys weren't working before on certain cedartrail laptops.
    
    The source of this problem is that the hotkeys' ASLE opregion interrupts
    were simply ignored. Driver seemed to expect the interrupt to be
    associated with a pipe, but it wasn't.
    
    Accepting the ASLE interrupt without an associated pipe event flag fixes
    the issue, the backlight code is called when needed, making the
    brightness keys work properly.
    
    [patrik: This patch affects irq handling on any netbook with opregion support]
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597
    Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.html
    Signed-off-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47d9848811228290f12d4bf04882215cfccbf9f1
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu May 2 00:52:01 2013 -0400

    drm/mgag200: deal with bo reserve fail in dirty update path
    
    commit 641719599528d806e00de8ae8c8453361266a312 upstream.
    
    On F19 testing, it was noticed we get a lot of errors in dmesg
    about being unable to reserve the buffer when plymouth starts,
    this is due to the buffer being in the process of migrating,
    so it makes sense we can't reserve it.
    
    In order to deal with it, this adds delayed updates for the dirty
    updates, when the bo is unreservable, in the normal console case
    this shouldn't ever happen, its just when plymouth or X is
    pushing the console bo to system memory.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52af8300d2a3478a621791f122bd9c4e3eb5840a
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu May 2 02:45:02 2013 -0400

    drm/cirrus: deal with bo reserve fail in dirty update path
    
    commit f3b2bbdc8a87a080ccd23d27fca4b87d61340dd4 upstream.
    
    Port over the mgag200 fix to cirrus as it suffers the same issue.
    
        On F19 testing, it was noticed we get a lot of errors in dmesg
        about being unable to reserve the buffer when plymouth starts,
        this is due to the buffer being in the process of migrating,
        so it makes sense we can't reserve it.
    
        In order to deal with it, this adds delayed updates for the dirty
        updates, when the bo is unreservable, in the normal console case
        this shouldn't ever happen, its just when plymouth or X is
        pushing the console bo to system memory.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5770e6e6d30ab6776797ff4328c73a6f55870447
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed Apr 24 08:52:50 2013 -0600

    block: fix max discard sectors limit
    
    commit 871dd9286e25330c8a581e5dacfa8b1dfe1dd641 upstream.
    
    linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with
    commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9
    (block: add plug for blkdev_issue_discard )
    
    For example,
    1) DISCARD rq-1 with size size 4GB
    2) DISCARD rq-2 with size size 1GB
    
    If these 2 discard requests get merged, final request size will be 5GB.
    
    In this case, request's __data_len field may overflow as it can store
    max 4GB(unsigned int).
    
    This issue was observed while doing mkfs.f2fs on 5GB SD card:
    https://lkml.org/lkml/2013/4/1/292
    
    Info: sector size = 512
    Info: total sectors = 11370496 (in 512bytes)
    Info: zone aligned segment0 blkaddr: 512
    [  257.789764] blk_update_request: bio idx 0 >= vcnt 0
    
    mkfs process gets stuck in D state and I see the following in the dmesg:
    
    [  257.789733] __end_that: dev mmcblk0: type=1, flags=122c8081
    [  257.789764]   sector 4194304, nr/cnr 2981888/4294959104
    [  257.789764]   bio df3840c0, biotail df3848c0, buffer   (null), len
    1526726656
    [  257.789764] blk_update_request: bio idx 0 >= vcnt 0
    [  257.794921] request botched: dev mmcblk0: type=1, flags=122c8081
    [  257.794921]   sector 4194304, nr/cnr 2981888/4294959104
    [  257.794921]   bio df3840c0, biotail df3848c0, buffer   (null), len
    1526726656
    
    This patch fixes this issue.
    
    Reported-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
    Tested-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0ca61ff1b18a11e7e7d085aa282a5593fb25126
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue May 7 16:57:06 2013 +0100

    arm64: Ignore the 'write' ESR flag on cache maintenance faults
    
    commit 0e7f7bcc3fc87489cda5aa6aff8ce40eed912279 upstream.
    
    ESR.WnR bit is always set on data cache maintenance faults even though
    the page is not required to have write permission. If a translation
    fault (page not yet mapped) happens for read-only user address range,
    Linux incorrectly assumes a permission fault. This patch adds the check
    of the ESR.CM bit during the page fault handling to ignore the 'write'
    flag.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Tim Northover <Tim.Northover@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d3a7eb266a154bbb90da4c7a9b992c4a3d75c22
Author: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date:   Mon Apr 1 20:13:39 2013 +0000

    RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled
    
    commit 5b0c275926b8149c555da874bb4ec258ea3292aa upstream.
    
    Commit c079c28714e4 ("RDMA/cxgb4: Fix error handling in create_qp()")
    broke SQ allocation.  Instead of falling back to host allocation when
    on-chip allocation fails, it tries to allocate both.  And when it
    does, and we try to free the address from the genpool using the host
    address, we hit a BUG and the system crashes as below.
    
    We create a new function that has the previous behavior and properly
    propagate the error, as intended.
    
        kernel BUG at /usr/src/packages/BUILD/kernel-ppc64-3.0.68/linux-3.0/lib/genalloc.c:340!
        Oops: Exception in kernel mode, sig: 5 [#1]
        SMP NR_CPUS=1024 NUMA pSeries
        Modules linked in: rdma_ucm rdma_cm ib_addr ib_cm iw_cm ib_sa ib_mad ib_uverbs iw_cxgb4 ib_core ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables fuse loop dm_mod ipv6 ipv6_lib sr_mod cdrom ibmveth(X) cxgb4 sg ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh ibmvscsic(X) scsi_transport_srp scsi_tgt scsi_mod
        Supported: Yes
        NIP: c00000000037d41c LR: d000000003913824 CTR: c00000000037d3b0
        REGS: c0000001f350ae50 TRAP: 0700   Tainted: G            X  (3.0.68-0.9-ppc64)
        MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24042482  XER: 00000001
        TASK = c0000001f6f2a840[3616] 'rping' THREAD: c0000001f3508000 CPU: 0
        GPR00: c0000001f6e875c8 c0000001f350b0d0 c000000000fc9690 c0000001f6e875c0
        GPR04: 00000000000c0000 0000000000010000 0000000000000000 c0000000009d482a
        GPR08: 000000006a170000 0000000000100000 c0000001f350b140 c0000001f6e875c8
        GPR12: d000000003915dd0 c000000003f40000 000000003e3ecfa8 c0000001f350bea0
        GPR16: c0000001f350bcd0 00000000003c0000 0000000000040100 c0000001f6e74a80
        GPR20: d00000000399a898 c0000001f6e74ac8 c0000001fad91600 c0000001f6e74ab0
        GPR24: c0000001f7d23f80 0000000000000000 0000000000000002 000000006a170000
        GPR28: 000000000000000c c0000001f584c8d0 d000000003925180 c0000001f6e875c8
        NIP [c00000000037d41c] .gen_pool_free+0x6c/0xf8
        LR [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
        Call Trace:
        [c0000001f350b0d0] [c0000001f350b180] 0xc0000001f350b180 (unreliable)
        [c0000001f350b170] [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4]
        [c0000001f350b210] [d00000000390fd70] .dealloc_sq+0x90/0xb0 [iw_cxgb4]
        [c0000001f350b280] [d00000000390fe08] .destroy_qp+0x78/0xf8 [iw_cxgb4]
        [c0000001f350b310] [d000000003912738] .c4iw_destroy_qp+0x208/0x2d0 [iw_cxgb4]
        [c0000001f350b460] [d000000003861874] .ib_destroy_qp+0x5c/0x130 [ib_core]
        [c0000001f350b510] [d0000000039911bc] .ib_uverbs_cleanup_ucontext+0x174/0x4f8 [ib_uverbs]
        [c0000001f350b5f0] [d000000003991568] .ib_uverbs_close+0x28/0x70 [ib_uverbs]
        [c0000001f350b670] [c0000000001e7b2c] .__fput+0xdc/0x278
        [c0000001f350b720] [c0000000001a9590] .remove_vma+0x68/0xd8
        [c0000001f350b7b0] [c0000000001a9720] .exit_mmap+0x120/0x160
        [c0000001f350b8d0] [c0000000000af330] .mmput+0x80/0x160
        [c0000001f350b960] [c0000000000b5d0c] .exit_mm+0x1ac/0x1e8
        [c0000001f350ba10] [c0000000000b8154] .do_exit+0x1b4/0x4b8
        [c0000001f350bad0] [c0000000000b84b0] .do_group_exit+0x58/0xf8
        [c0000001f350bb60] [c0000000000ce9f4] .get_signal_to_deliver+0x2f4/0x5d0
        [c0000001f350bc60] [c000000000017ee4] .do_signal_pending+0x6c/0x3e0
        [c0000001f350bdb0] [c0000000000182cc] .do_signal+0x74/0x78
        [c0000001f350be30] [c000000000009e74] do_work+0x24/0x28
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
    Cc: Emil Goode <emilgoode@gmail.com>
    Acked-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f9cc57937dfbe59c25f66e801bfecf5cb0de031
Author: Stefan Bader <stefan.bader@canonical.com>
Date:   Fri Apr 26 13:49:32 2013 +0000

    r8169: fix 8168evl frame padding.
    
    commit e5195c1f31f399289347e043d6abf3ffa80f0005 upstream.
    
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Cc: hayeswang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f6aad0d018d11878d49603e017d3f6480488f41
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Apr 21 22:56:32 2013 -0400

    ext4: add check for inodes_count overflow in new resize ioctl
    
    commit 3f8a6411fbada1fa482276591e037f3b1adcf55b upstream.
    
    Addresses-Red-Hat-Bugzilla: #913245
    
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6be0e000f32e975c79852d2d990a09cad41fc605
Author: Matthias Schiffer <mschiffer@universe-factory.net>
Date:   Sat Mar 30 10:23:12 2013 +0000

    netfilter: ip6t_NPT: Fix translation for non-multiple of 32 prefix lengths
    
    commit 906b1c394d0906a154fbdc904ca506bceb515756 upstream.
    
    The bitmask used for the prefix mangling was being calculated
    incorrectly, leading to the wrong part of the address being replaced
    when the prefix length wasn't a multiple of 32.
    
    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fc08dc6f89960aaf27149f8031009fdc8062a70
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Apr 17 22:45:24 2013 +0000

    netfilter: xt_rpfilter: skip locally generated broadcast/multicast, too
    
    commit f83a7ea2075ca896f2dbf07672bac9cf3682ff74 upstream.
    
    Alex Efros reported rpfilter module doesn't match following packets:
    IN=br.qemu SRC=192.168.2.1 DST=192.168.2.255 [ .. ]
    (netfilter bugzilla #814).
    
    Problem is that network stack arranges for the locally generated broadcasts
    to appear on the interface they were sent out, so the IFF_LOOPBACK check
    doesn't trigger.
    
    As -m rpfilter is restricted to PREROUTING, we can check for existing
    rtable instead, it catches locally-generated broad/multicast case, too.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79293de3160850689a436a072f51037493db73b8
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Feb 11 23:22:38 2013 +0000

    netfilter: ctnetlink: don't permit ct creation with random tuple
    
    commit 442fad9423b78319e0019a7f5047eddf3317afbc upstream.
    
    Userspace can cause kernel panic by not specifying orig/reply
    tuple: kernel will create a tuple with random stack values.
    
    Problem is that tuple.dst.dir will be random, too, which
    causes nf_ct_tuplehash_to_ctrack() to return garbage.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc27819bea8a7791c8a95e0db258389d3cb00887
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 12 05:59:53 2013 +0000

    netfilter: nf_ct_helper: don't discard helper if it is actually the same
    
    commit 6e2f0aa8cf8892868bf2c19349cb5d7c407f690d upstream.
    
    commit (32f5376 netfilter: nf_ct_helper: disable automatic helper
    re-assignment of different type) broke transparent proxy scenarios.
    
    For example, initial helper lookup might yield "ftp" (dport 21),
    while re-lookup after REDIRECT yields "ftp-2121".
    
    This causes the autoassign code to toss the ftp helper, even
    though these are just different instances of the same helper.
    
    Change the test to check for the helper function address instead
    of the helper address, as suggested by Pablo.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf75e569817b1311815cafe2ea39110e706479e0
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Thu Feb 21 11:12:40 2013 +0100

    netfilter: ipset: "Directory not empty" error message
    
    commit dd82088dab3646ed28e4aa43d1a5b5d5ffc2afba upstream.
    
    When an entry flagged with "nomatch" was tested by ipset, it
    returned the error message "Kernel error received:
    Directory not empty" instead of "<element> is NOT in set <setname>"
    (reported by John Brendler).
    
    The internal error code was not properly transformed before returning
    to userspace, fixed.
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc73e38cee0626945a70cb0c2d873aaae3795130
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 08:13:30 2013 +0000

    netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet
    
    commit 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.
    
    Some Cisco phones create huge messages that are spread over multiple packets.
    After calculating the offset of the SIP body, it is validated to be within
    the packet and the packet is dropped otherwise. This breaks operation of
    these phones. Since connection tracking is supposed to be passive, just let
    those packets pass unmodified and untracked.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41a460c403b5157c4c7b93190688b897c2d78313
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Tue Apr 9 08:57:19 2013 +0000

    netfilter: ipset: list:set: fix reference counter update
    
    commit 02f815cb6d3f57914228be84df9613ee5a01c2e6 upstream.
    
    The last element can be replaced or pushed off and in both
    cases the reference counter must be updated.
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0b95c5fdefb0e9eca0c1754ef4e2fa84323ff96
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Apr 11 04:22:39 2013 +0000

    netfilter: nf_nat: fix race when unloading protocol modules
    
    commit c2d421e171868586939c328dfb91bab840fe4c49 upstream.
    
    following oops was reported:
    RIP: 0010:[<ffffffffa03227f2>]  [<ffffffffa03227f2>] nf_nat_cleanup_conntrack+0x42/0x70 [nf_nat]
    RSP: 0018:ffff880202c63d40  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff8801ac7bec28 RCX: ffff8801d0eedbe0
    RDX: dead000000200200 RSI: 0000000000000011 RDI: ffffffffa03265b8
    [..]
    Call Trace:
     [..]
     [<ffffffffa02febed>] destroy_conntrack+0xbd/0x110 [nf_conntrack]
    
    Happens when a conntrack timeout expires right after first part
    of the nat cleanup has completed (bysrc hash removal), but before
    part 2 has completed (re-initialization of nat area).
    
    [ destroy callback tries to delete bysrc again ]
    
    Patrick suggested to just remove the affected conntracks -- the
    connections won't work properly anyway without nat transformation.
    
    So, lets do that.
    
    Reported-by: CAI Qian <caiqian@redhat.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 023477dfd365edcbca4e157b72f7c4bd099fed81
Author: Hans Schillstrom <hans@schillstrom.com>
Date:   Sat Apr 27 20:06:14 2013 +0200

    ipvs: ip_vs_sip_fill_param() BUG: bad check of return value
    
    commit f7a1dd6e3ad59f0cfd51da29dfdbfd54122c5916 upstream.
    
    The reason for this patch is crash in kmemdup
    caused by returning from get_callid with uniialized
    matchoff and matchlen.
    
    Removing Zero check of matchlen since it's done by ct_sip_get_header()
    
    BUG: unable to handle kernel paging request at ffff880457b5763f
    IP: [<ffffffff810df7fc>] kmemdup+0x2e/0x35
    PGD 27f6067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in: xt_state xt_helper nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle xt_connmark xt_conntrack ip6_tables nf_conntrack_ftp ip_vs_ftp nf_nat xt_tcpudp iptable_mangle xt_mark ip_tables x_tables ip_vs_rr ip_vs_lblcr ip_vs_pe_sip ip_vs nf_conntrack_sip nf_conntrack bonding igb i2c_algo_bit i2c_core
    CPU 5
    Pid: 0, comm: swapper/5 Not tainted 3.9.0-rc5+ #5                  /S1200KP
    RIP: 0010:[<ffffffff810df7fc>]  [<ffffffff810df7fc>] kmemdup+0x2e/0x35
    RSP: 0018:ffff8803fea03648  EFLAGS: 00010282
    RAX: ffff8803d61063e0 RBX: 0000000000000003 RCX: 0000000000000003
    RDX: 0000000000000003 RSI: ffff880457b5763f RDI: ffff8803d61063e0
    RBP: ffff8803fea03658 R08: 0000000000000008 R09: 0000000000000011
    R10: 0000000000000011 R11: 00ffffffff81a8a3 R12: ffff880457b5763f
    R13: ffff8803d67f786a R14: ffff8803fea03730 R15: ffffffffa0098e90
    FS:  0000000000000000(0000) GS:ffff8803fea00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff880457b5763f CR3: 0000000001a0c000 CR4: 00000000001407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper/5 (pid: 0, threadinfo ffff8803ee18c000, task ffff8803ee18a480)
    Stack:
     ffff8803d822a080 000000000000001c ffff8803fea036c8 ffffffffa000937a
     ffffffff81f0d8a0 000000038135fdd5 ffff880300000014 ffff880300110000
     ffffffff150118ac ffff8803d7e8a000 ffff88031e0118ac 0000000000000000
    Call Trace:
     <IRQ>
    
     [<ffffffffa000937a>] ip_vs_sip_fill_param+0x13a/0x187 [ip_vs_pe_sip]
     [<ffffffffa007b209>] ip_vs_sched_persist+0x2c6/0x9c3 [ip_vs]
     [<ffffffff8107dc53>] ? __lock_acquire+0x677/0x1697
     [<ffffffff8100972e>] ? native_sched_clock+0x3c/0x7d
     [<ffffffff8100972e>] ? native_sched_clock+0x3c/0x7d
     [<ffffffff810649bc>] ? sched_clock_cpu+0x43/0xcf
     [<ffffffffa007bb1e>] ip_vs_schedule+0x181/0x4ba [ip_vs]
    ...
    
    Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfc8f2cebe1dfda582e128c63d8cd6a1cebfe751
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Mar 18 10:19:51 2013 -0700

    xhci: Don't warn on empty ring for suspended devices.
    
    commit a83d6755814e4614ba77e15d82796af0f695c6b8 upstream.
    
    When a device attached to the roothub is suspended, the endpoint rings
    are stopped.  The host may generate a completion event with the
    completion code set to 'Stopped' or 'Stopped Invalid' when the ring is
    halted.  The current xHCI code prints a warning in that case, which can
    be really annoying if the USB device is coming into and out of suspend.
    
    Remove the unnecessary warning.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Stephen Hemminger <stephen@networkplumber.org>
    Cc: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b241f9dc4c1f736711d8ea471de604a97807454f
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Wed May 8 12:10:25 2013 +0400

    e1000e: fix accessing to suspended device
    
    commit e60b22c5b7e59db09a7c9490b1e132c7e49ae904 upstream.
    
    This patch fixes some annoying messages like 'Error reading PHY register' and
    'Hardware Erorr' and saves several seconds on reboot.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Bruce Allan <bruce.w.allan@intel.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Borislav Petkov <bp@suse.de>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Tested-by: Tóth Attila <atoth@atoth.sote.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f38a22c6fde1ae94fbc3fd2f382f03a1e0d617eb
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Wed May 8 12:10:21 2013 +0400

    e1000e: fix runtime power management transitions
    
    commit 66148babe728f3e00e13c56f6b0ecf325abd80da upstream.
    
    This patch removes redundant actions from driver and fixes its interaction
    with actions in pci-bus runtime power management code.
    
    It removes pci_save_state() from __e1000_shutdown() for normal adapters,
    PCI bus callbacks pci_pm_*() will do all this for us. Now __e1000_shutdown()
    switches to D3-state only quad-port adapters, because they needs quirk for
    clearing false-positive error from downsteam pci-e port.
    
    pci_save_state() now called after clearing bus-master bit, thus __e1000_resume()
    and e1000_io_slot_reset() must set it back after restoring configuration space.
    
    This patch set get_link_status before calling pm_runtime_put() in e1000_open()
    to allow e1000_idle() get real link status and schedule first runtime suspend.
    
    This patch also enables wakeup for device if management mode is enabled
    (like for WoL) as result pci_prepare_to_sleep() would setup wakeup without
    special actions like custom 'enable_wakeup' sign.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Bruce Allan <bruce.w.allan@intel.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Borislav Petkov <bp@suse.de>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Tested-by: Tóth Attila <atoth@atoth.sote.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c698c715dc47e7eaa33cbbc52cf79c7c4ee45231
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed May 8 12:10:18 2013 +0400

    PCI/PM: Clear state_saved during suspend
    
    commit 82fee4d67ab86d6fe5eb0f9a9e988ca9d654d765 upstream.
    
    This patch clears pci_dev->state_saved at the beginning of suspending.
    PCI config state may be saved long before that.  Some drivers call
    pci_save_state() from the ->probe() callback to get snapshot of sane
    configuration space to use in the ->slot_reset() callback.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> # add comment
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Tóth Attila <atoth@atoth.sote.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea28b081461d472c0f2719fb22e81d6a00e80698
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri May 3 14:11:25 2013 +0200

    perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
    
    commit 7cc23cd6c0c7d7f4bee057607e7ce01568925717 upstream.
    
    We should always have proper privileges when requesting kernel
    data.
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: eranian@google.com
    Link: http://lkml.kernel.org/r/20130503121256.230745028@chello.nl
    [ Fix build error reported by fengguang.wu@intel.com, propagate error code back. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ed6f50aa0a5189f85d97327a2b8e3f33cbf190a
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri May 3 14:11:24 2013 +0200

    perf/x86/intel/lbr: Fix LBR filter
    
    commit 6e15eb3ba6c0249c9e8c783517d131b47db995ca upstream.
    
    The LBR 'from' adddress is under full userspace control; ensure
    we validate it before reading from it.
    
    Note: is_module_text_address() can potentially be quite
    expensive; for those running into that with high overhead
    in modules optimize it using an RCU backed rb-tree.
    
    Reported-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: eranian@google.com
    Link: http://lkml.kernel.org/r/20130503121256.158211806@chello.nl
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/n/tip-mk8i82ffzax01cnqo829iy1q@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eac4db22f37a4048b22fb963e2907db5b87dbd5
Author: Jan-Simon Möller <dl9pf@gmx.de>
Date:   Tue Apr 30 12:02:33 2013 +0200

    perf/x86/intel: Fix unintended variable name reuse
    
    commit 1b0dac2ac6debdbf1541e15f2cede03613cf4465 upstream.
    
    The variable name events_group is already in used and led to a
    compilation error when using clang to build the Linux Kernel .
    The fix is just to rename the var. No functional change. Please
    apply.
    
    Fix suggested in discussion by PaX Team <pageexec@freemail.hu>
    
    Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
    Cc: rostedt@goodmis.org
    Cc: a.p.zijlstra@chello.nl
    Cc: paulus@samba.org
    Cc: acme@ghostprotocols.net
    Link: http://lkml.kernel.org/r/1367316153-14808-1-git-send-email-dl9pf@gmx.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aab55611aa0e243b360b14d25416b52095238965
Author: Vince Weaver <vincent.weaver@maine.edu>
Date:   Mon Apr 29 15:52:27 2013 -0400

    perf/x86/intel: Add support for IvyBridge model 58 Uncore
    
    commit 9a6bc14350b130427725f33e371e86212fa56c85 upstream.
    
    According to Intel Vol3b 18.9, the IvyBridge model 58 uncore is
    the same as that of SandyBridge.
    
    I've done some simple tests and with this patch things seem to
    work on my mac-mini.
    
    Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Cc: Stephane Eranian <eranian@gmail.com>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1304291549320.15827@vincent-weaver-1.um.maine.edu
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f20d7b5787463886691a0946cc5b56153538df47
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri May 3 17:19:01 2013 +0000

    net/eth/ibmveth: Fixup retrieval of MAC address
    
    commit 13f85203e1060da83d9ec1c1c5a63343eaab8de4 upstream.
    
    Some ancient pHyp versions used to create a 8 bytes local-mac-address
    property in the device-tree instead of a 6 bytes one for veth.
    
    The Linux driver code to deal with that is an insane hack which also
    happens to break with some choices of MAC addresses in qemu by testing
    for a bit in the address rather than just looking at the size of the
    property.
    
    Sanitize this by doing the latter instead.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d474ea53485a4a81699f503c8234610af7fb8c3c
Author: Joerg Roedel <joro@8bytes.org>
Date:   Tue Apr 9 21:14:08 2013 +0200

    iommu/amd: Properly initialize irq-table lock
    
    commit 197887f03daecdb3ae21bafeb4155412abad3497 upstream.
    
    Fixes a lockdep warning.
    
    Reviewed-by: Shuah Khan <shuahkhan@gmail.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffeae73e9f2780c7711b12b78ade0a447665117c
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Tue May 7 16:18:13 2013 -0700

    hugetlbfs: fix mmap failure in unaligned size request
    
    commit af73e4d9506d3b797509f3c030e7dcd554f7d9c4 upstream.
    
    The current kernel returns -EINVAL unless a given mmap length is
    "almost" hugepage aligned.  This is because in sys_mmap_pgoff() the
    given length is passed to vm_mmap_pgoff() as it is without being aligned
    with hugepage boundary.
    
    This is a regression introduced in commit 40716e29243d ("hugetlbfs: fix
    alignment of huge page requests"), where alignment code is pushed into
    hugetlb_file_setup() and the variable len in caller side is not changed.
    
    To fix this, this patch partially reverts that commit, and adds
    alignment code in caller side.  And it also introduces hstate_sizelog()
    in order to get proper hstate to specified hugepage size.
    
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=56881
    
    [akpm@linux-foundation.org: fix warning when CONFIG_HUGETLB_PAGE=n]
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: <iceman_dvd@yahoo.com>
    Cc: Steven Truelove <steven.truelove@utoronto.ca>
    Cc: Jianguo Wu <wujianguo@huawei.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f9bc00875dd46bc964b37825ba6bb2024a365e4
Author: David Jeffery <djeffery@redhat.com>
Date:   Mon May 6 13:49:30 2013 +0800

    autofs - remove autofs dentry mount check
    
    commit ce8a5dbdf9e709bdaf4618d7ef8cceb91e8adc69 upstream.
    
    When checking if an autofs mount point is busy it isn't sufficient to
    only check if it's a mount point.
    
    For example, if the mount of an offset mountpoint in a tree is denied
    for this host by its export and the dentry becomes a process working
    directory the check incorrectly returns the mount as not in use at
    expire.
    
    This can happen since the default when mounting within a tree is
    nostrict, which means ingnore mount fails on mounts within the tree and
    continue.  The nostrict option is meant to allow mounting in this case.
    
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Ian Kent <raven@themaw.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 228c19cd8f6d576dc6ab7d641b59aacc98952b9f
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sat Mar 30 20:43:22 2013 +0800

    pwm: spear: Fix checking return value of clk_enable() and clk_prepare()
    
    commit 563861cd633ae52932843477bb6ca3f1c9e2f78b upstream.
    
    The logic to check return value of clk_enable() and clk_prepare() is reversed,
    fix it.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0b0e8d3666ccd7faa037a763cb6d837bf9c4f32
Author: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Date:   Fri Mar 22 05:49:35 2013 +0000

    powerpc: fix numa distance for form0 device tree
    
    commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream.
    
    The following commit breaks numa distance setup for old powerpc
    systems that use form0 encoding in device tree.
    
    commit 41eab6f88f24124df89e38067b3766b7bef06ddb
    powerpc/numa: Use form 1 affinity to setup node distance
    
    Device tree node /rtas/ibm,associativity-reference-points would
    index into /cpus/PowerPCxxxx/ibm,associativity based on form0 or
    form1 encoding detected by ibm,architecture-vec-5 property.
    
    All modern systems use form1 and current kernel code is correct.
    However, on older systems with form0 encoding, the numa distance
    will get hard coded as LOCAL_DISTANCE for all nodes.  This causes
    task scheduling anomaly since scheduler will skip building numa
    level domain (topmost domain with all cpus) if all numa distances
    are same.  (value of 'level' in sched_init_numa() will remain 0)
    
    Prior to the above commit:
    ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE)
    
    Restoring compatible behavior with this patch for old powerpc systems
    with device tree where numa distance are encoded as form0.
    
    Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c4aedfd654c665080f9e3df38725c65b14be042
Author: Anton Blanchard <anton@samba.org>
Date:   Wed May 1 20:06:33 2013 +0000

    powerpc: Emulate non privileged DSCR read and write
    
    commit 73d2fb758e678c93bc76d40876c2359f0729b0ef upstream.
    
    POWER8 allows read and write of the DSCR in userspace. We added
    kernel emulation so applications could always use the instructions
    regardless of the CPU type.
    
    Unfortunately there are two SPRs for the DSCR and we only added
    emulation for the privileged one. Add code to match the non
    privileged one.
    
    A simple test was created to verify the fix:
    
    http://ozlabs.org/~anton/junkcode/user_dscr_test.c
    
    Without the patch we get a SIGILL and it passes with the patch.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6a35381c7142ad8dc0f0f76b7c2bd6d6dd64477
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Thu Apr 25 13:53:09 2013 +0000

    xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq
    
    commit 2798ba7d19aed645663398a21ec4006bfdbb1ef3 upstream.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: Ian Campbell <ian.camjpbell@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>