commit ea88a24912c191babee3a3a2658ade2d53b880a9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 11 13:38:25 2013 -0700

    Linux 3.0.78

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

    Revert "x86, amd: Disable way access filter on Piledriver CPUs" it is duplicated
    
    Revert 5e3fe67e02c53e5a5fcf0e2b0d91dd93f757d50b which is
    commit 2bbf0a1427c377350f001fbc6260995334739ad7 upstream.
    
    Willy pointed out that I messed up and applied this one twice to the
    3.0-stable tree, so revert the second instance of it.
    
    Reported by: Willy Tarreau <w@1wt.eu>
    Cc: Andre Przywara <osp@andrep.de>
    Cc: H. Peter Anvin <hpa@linux.intel.com>
    Cc: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    reverted:

commit dadd72be605e99445bedfacce8d07a85ac84eb41
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 d47f90f3cb58908bb6f6720b678e37e57028a590
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 07bdcd24805f6c492c5871dac365f7ce0a331044
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 82bab2b3b6d6029b06a4e85156ccf99bf95cc2f2
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 b085d867934932a43188297161a5fbbe07565b4c
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 370112b115a3867b2ebf0ac6a2f44f11425fe818
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 b1459cd57d01eb554821bf263463ef18bc1f59ef
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 c2fde23d77ebcf4577fdd703af8b1600f3c87f69
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 df859ddd0675a729e4108da5bd9c3ac9618441f2
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 332400ff82e7d3ea465bf62d46c87953f59a118b
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 eda948e04f7804886db45005eae5793a6ffb0bbc
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 5013bcf5cbd6969b8873b964e0d7aaab430cf643
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>