commit 07c4ee001f13f489364c37dcd4947670da26a489
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 3 18:27:30 2013 -0600

    Linux 3.7.6

commit 8aec109e2abc91dee186d2b11eb550b763ae2791
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jan 10 12:42:15 2013 +0100

    netfilter: xt_CT: fix unset return value if conntrack zone are disabled
    
    commit 4610476d89d53714ca94aae081fa035908bc137a upstream.
    
    net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v1’:
    net/netfilter/xt_CT.c:250:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v0’:
    net/netfilter/xt_CT.c:112:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    
    Reported-by: Borislav Petkov <bp@alien8.de>
    Acked-by: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08423e3fa52d9432e4ef82c88d6b943f49c2696f
Author: CAI Qian <caiqian@redhat.com>
Date:   Thu Jan 24 22:50:09 2013 -0500

    slub: assign refcount for kmalloc_caches
    
    This is for stable-3.7.y only and this problem has already been solved
    in mainline through some slab/slub re-work which isn't suitable to
    backport here. See create_kmalloc_cache() in mm/slab_common.c there.
    
    commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache
    refcounting to common code') moves some refcount manipulation code to
    common code. Unfortunately, it also removed refcount assignment for
    kmalloc_caches. So, kmalloc_caches's refcount is initially 0.
    This makes erroneous situation.
    
    Paul Hargrove report that when he create a 8-byte kmem_cache and
    destory it, he encounter below message.
    'Objects remaining in kmalloc-8 on kmem_cache_close()'
    
    8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is
    increased by one. So, resulting refcount is 1. When destroy it, it hit
    refcount = 0, then kmem_cache_close() is executed and error message is
    printed.
    
    This patch assign initial refcount 1 to kmalloc_caches, so fix this
    erroneous situation.
    
    Reported-by: Paul Hargrove <phhargrove@lbl.gov>
    Cc: Christoph Lameter <cl@linux.com>
    Signed-off-by: Joonsoo Kim <js1304@gmail.com>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec8a7ca08363c563f77ea9d38727822de46a3887
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Jan 17 10:24:09 2013 +0200

    drm/i915: fix FORCEWAKE posting reads
    
    commit b514407547890686572606c9dfa4b7f832db9958 upstream.
    
    We stopped reading FORCEWAKE for posting reads in
    
    commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
    Author: Ben Widawsky <ben@bwidawsk.net>
    Date:   Sat Sep 1 22:59:50 2012 -0700
    
        drm/i915: Never read FORCEWAKE
    
    and started using something from the same cacheline instead. On the
    bug reporter's machine this broke entering rc6 states after a
    suspend/resume cycle. It turns out reading ECOBUS as posting read
    worked fine, while GTFIFODBG did not, preventing RC6 states after
    suspend/resume per the bug report referenced below. It's not entirely
    clear why, but clearly GTFIFODBG was nowhere near the same cacheline
    or address range as FORCEWAKE.
    
    Trying out various registers for posting reads showed that all tested
    registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
    work. Conversely, most (but not quite all) registers for which
    NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
    bug.
    
    Based on the above, add posting reads on ECOBUS where GTFIFODBG was
    previously relied on.
    
    In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
    well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
    address range as FORCEWAKE_VLV.
    
    v2: Add more details to the commit message. No functional changes.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
    Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru>
    CC: Ben Widawsky <ben@bwidawsk.net>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org
    [danvet: add cc: stable and make the commit message a bit clearer that
    this is a regression fix and what exactly broke.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fae56feb6210422096d1886516022a3eedc515c9
Author: Jesper Juhl <jj@chaosbits.net>
Date:   Wed Dec 26 11:49:40 2012 +0000

    netfilter: ctnetlink: fix leak in error path of ctnetlink_create_expect
    
    commit 1310b955c804975651dca6c674ebfd1cb2b4c7ff upstream.
    
    This patch fixes a leak in one of the error paths of
    ctnetlink_create_expect if no helper and no timeout is specified.
    
    Signed-off-by: Jesper Juhl <jj@chaosbits.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff89a34cb5b28ed5eb35056fffe4cff380537c3d
Author: Jan Engelhardt <jengelh@inai.de>
Date:   Thu Jan 10 12:30:05 2013 +0000

    netfilter: x_tables: print correct hook names for ARP
    
    commit 5b76c4948fe6977bead2359c2054f3e6a2dcf3d0 upstream.
    
    arptables 0.0.4 (released on 10th Jan 2013) supports calling the
    CLASSIFY target, but on adding a rule to the wrong chain, the
    diagnostic is as follows:
    
    	# arptables -A INPUT -j CLASSIFY --set-class 0:0
    	arptables: Invalid argument
    	# dmesg | tail -n1
    	x_tables: arp_tables: CLASSIFY target: used from hooks
    	PREROUTING, but only usable from INPUT/FORWARD
    
    This is incorrect, since xt_CLASSIFY.c does specify
    (1 << NF_ARP_OUT) | (1 << NF_ARP_FORWARD).
    
    This patch corrects the x_tables diagnostic message to print the
    proper hook names for the NFPROTO_ARP case.
    
    Affects all kernels down to and including v2.6.31.
    
    Signed-off-by: Jan Engelhardt <jengelh@inai.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db091405c3222a00987d546f8758cb33ad9649c7
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jan 10 16:12:01 2013 +0100

    netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns
    
    commit 1e47ee8367babe6a5e8adf44a714c7086657b87e upstream.
    
    canqun zhang reported that we're hitting BUG_ON in the
    nf_conntrack_destroy path when calling kfree_skb while
    rmmod'ing the nf_conntrack module.
    
    Currently, the nf_ct_destroy hook is being set to NULL in the
    destroy path of conntrack.init_net. However, this is a problem
    since init_net may be destroyed before any other existing netns
    (we cannot assume any specific ordering while releasing existing
    netns according to what I read in recent emails).
    
    Thanks to Gao feng for initial patch to address this issue.
    
    Reported-by: canqun zhang <canqunzhang@gmail.com>
    Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99740d8bf1a78bcfd85072d2396847488a565b68
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 3 22:18:39 2013 +0000

    netfilter: xt_recent: avoid high order page allocations
    
    commit 2727de76041b2064c0b74f00a2a89678fb3efafc upstream.
    
    xt_recent can try high order page allocations and this can fail.
    
    iptables: page allocation failure: order:9, mode:0xc0d0
    
    It also wastes about half the allocated space because of kmalloc()
    power-of-two roundups and struct recent_table layout.
    
    Use vmalloc() instead to save space and be less prone to allocation
    errors when memory is fragmented.
    
    Reported-by: Miroslav Kratochvil <exa.exa@gmail.com>
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-by: Harald Reindl <h.reindl@thelounge.net>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98dbbfa183f5abbbe582c1ba53b8bfac9e7ed37e
Author: Vitaly E. Lavrov <lve@guap.ru>
Date:   Mon Dec 24 13:55:20 2012 +0100

    netfilter: xt_recent: fix namespace destroy path
    
    commit 665e205c16c1f902ac6763b8ce8a0a3a1dcefe59 upstream.
    
    recent_net_exit() is called before recent_mt_destroy() in the
    destroy path of network namespaces. Make sure there are no entries
    in the parent proc entry xt_recent before removing it.
    
    Signed-off-by: Vitaly E. Lavrov <lve@guap.ru>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9be8ff2dc372797024d2ddf92c7218d75fe2f82
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Dec 24 13:09:25 2012 +0100

    netfilter: xt_hashlimit: fix race that results in duplicated entries
    
    commit 09181842b000344b1205801df3aa5b726c03cc62 upstream.
    
    Two packets may race to create the same entry in the hashtable,
    double check if this packet lost race. This double checking only
    happens in the path of the packet that creates the hashtable for
    first time.
    
    Note that, with this patch, no packet drops occur if the race happens.
    
    Reported-by: Feng Gao <gfree.wind@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30eb9ef340b168fda569ad288404cc82ba7da90c
Author: Vitaly E. Lavrov <lve@guap.ru>
Date:   Mon Dec 24 14:42:17 2012 +0100

    netfilter: xt_hashlimit: fix namespace destroy path
    
    commit 32263dd1b43378b4f7d7796ed713f77e95f27e8a upstream.
    
    recent_net_exit() is called before recent_mt_destroy() in the
    destroy path of network namespaces. Make sure there are no entries
    in the parent proc entry xt_recent before removing it.
    
    Signed-off-by: Vitaly E. Lavrov <lve@guap.ru>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85530f181aa1df0e54c595fd6b8ef506222b99c2
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jan 2 16:30:01 2013 +0000

    netfilter: fix missing dependencies for the NOTRACK target
    
    commit 757ae316fb35811cfd8c67de0e0b8680ec4c1f37 upstream.
    
    warning: (NETFILTER_XT_TARGET_NOTRACK) selects NETFILTER_XT_TARGET_CT which has unmet direct
    +dependencies (NET && INET && NETFILTER && NETFILTER_XTABLES && NF_CONNTRACK && (IP_NF_RAW ||
    +IP6_NF_RAW) && NETFILTER_ADVANCED)
    
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d401aadc261edfcea6d9e7b794d0629cb24518a9
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Dec 20 01:54:51 2012 +0000

    netfilter: xt_CT: recover NOTRACK target support
    
    commit 10db9069eb5c60195170a4119bdbcbce69a4945f upstream.
    
    Florian Westphal reported that the removal of the NOTRACK target
    (9655050 netfilter: remove xt_NOTRACK) is breaking some existing
    setups.
    
    That removal was scheduled for removal since long time ago as
    described in Documentation/feature-removal-schedule.txt
    
    What:  xt_NOTRACK
    Files: net/netfilter/xt_NOTRACK.c
    When:  April 2011
    Why:   Superseded by xt_CT
    
    Still, people may have not notice / may have decided to stick to an
    old iptables version. I agree with him in that some more conservative
    approach by spotting some printk to warn users for some time is less
    agressive.
    
    Current iptables 1.4.16.3 already contains the aliasing support
    that makes it point to the CT target, so upgrading would fix it.
    Still, the policy so far has been to avoid pushing our users to
    upgrade.
    
    As a solution, this patch recovers the NOTRACK target inside the CT
    target and it now spots a warning.
    
    Reported-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 11be9a19f21d08bface2c48f848beaeeb813a68f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Dec 17 01:12:00 2012 +0100

    netfilter: nfnetlink_log: fix possible compilation issue due to missing include
    
    commit e035edd16ee83498cccc9beedfc215e15cab3a07 upstream.
    
    In (0c36b48 netfilter: nfnetlink_log: fix mac address for 6in4 tunnels)
    the include file that defines ARPD_SIT was missing. This passed unnoticed
    during my tests (I did not hit this problem here).
    
    net/netfilter/nfnetlink_log.c: In function '__build_packet_message':
    net/netfilter/nfnetlink_log.c:494:25: error: 'ARPHRD_SIT' undeclared (first use in this function)
    net/netfilter/nfnetlink_log.c:494:25: note: each undeclared identifier is reported only once for
    +each function it appears in
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

commit f8ff3de47653aee6cb92a148fa6dae94147482c6
Author: Bob Hockney <bhockney@ix.netcom.com>
Date:   Sun Dec 16 19:34:11 2012 +0100

    netfilter: nfnetlink_log: fix mac address for 6in4 tunnels
    
    commit 0c36b48b36dc84d4215dc9d1cde1bda829214ba6 upstream.
    
    For tunnelled ipv6in4 packets, the LOG target (xt_LOG.c) adjusts
    the start of the mac field to start at the ethernet header instead
    of the ipv4 header for the tunnel. This patch conforms what is
    passed by the NFLOG target through nfnetlink to what the LOG target
    does. Code borrowed from xt_LOG.c.
    
    Signed-off-by: Bob Hockney <bhockney@ix.netcom.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b62b8fa198079c0e2a829f38557fcae4cffa017
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jan 24 21:57:14 2013 -0500

    target: fix regression with dev_link_magic in target_fabric_port_link
    
    This is to fix a regression that only affect the stable (not for the mainline)
    that the stable commit fdf9d86 was incorrectly placed dev->dev_link_magic check
    before the *dev assignment in target_fabric_port_link() due to fuzzy automatically
    context adjustment during the back-porting.
    
    Reported-by: Chris Boot <bootc@bootc.net>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8121aecbe073a880758ab5464a305361dbcb7134
Author: Dave Chinner <dchinner@redhat.com>
Date:   Fri Jan 25 12:45:07 2013 -0600

    xfs: fix periodic log flushing
    
    [Please take this patch for -stable in kernels 3.5-3.7.  It doesn't have an
    equivalent upstream commit because the code was removed before the bug was
    discovered.  See f661f1e0bf50 and 7e18530bef6a.]
    
    There is a logic inversion in xfssyncd_worker() which means that the
    log is not periodically forced or idled correctly. This means that
    metadata changes aggregated in memory do not get flushed in a timely
    manner, and hence if filesystem is not cleanly unmounted those
    changes can be lost. This loss can manifest itself even hours after
    the changes were made if the filesystem is left to idle without a
    sync() occurring between the last modification and the
    crash/shutdown occuring.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8525659e782fa14ce8baa2b197d03dac3a7cc90
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Sun Jan 13 20:56:41 2013 -0800

    x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
    
    commit e43b3cec711a61edf047adf6204d542f3a659ef8 upstream.
    
    early_pci_allowed() and read_pci_config_16() are only available if
    CONFIG_PCI is defined.
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>

commit 950d73bf1b0da05186948457cdc4b957d5dbdc7c
Author: Haibo Xi <haibbo@gmail.com>
Date:   Thu Dec 6 23:42:17 2012 +0000

    netfilter: nf_ct_reasm: fix conntrack reassembly expire code
    
    commit 97cf00e93cc24898493e7a058105e3215257ee04 upstream.
    
    Commit b836c99fd6c9 (ipv6: unify conntrack reassembly expire
    code with standard one) use the standard IPv6 reassembly
    code(ip6_expire_frag_queue) to handle conntrack reassembly expire.
    
    In ip6_expire_frag_queue, it invoke dev_get_by_index_rcu to get
    which device received this expired packet.so we must save ifindex
    when NF_conntrack get this packet.
    
    With this patch applied, I can see ICMP Time Exceeded sent
    from the receiver when the sender sent out 1/2 fragmented
    IPv6 packet.
    
    Signed-off-by: Haibo Xi <haibbo@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93beec7f7bba67a025f4038ebfadaa8d14c9042e
Author: Mukund Jampala <jbmukund@gmail.com>
Date:   Sun Dec 16 19:25:58 2012 +0100

    netfilter: ip[6]t_REJECT: fix wrong transport header pointer in TCP reset
    
    commit c6f408996c625cb950cad024f90e50519f94713c upstream.
    
    The problem occurs when iptables constructs the tcp reset packet.
    It doesn't initialize the pointer to the tcp header within the skb.
    When the skb is passed to the ixgbe driver for transmit, the ixgbe
    driver attempts to access the tcp header and crashes.
    Currently, other drivers (such as our 1G e1000e or igb drivers) don't
    access the tcp header on transmit unless the TSO option is turned on.
    
    <1>BUG: unable to handle kernel NULL pointer dereference at 0000000d
    <1>IP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe]
    <4>*pdpt = 0000000085e5d001 *pde = 0000000000000000
    <0>Oops: 0000 [#1] SMP
    [...]
    <4>Pid: 0, comm: swapper Tainted: P            2.6.35.12 #1 Greencity/Thurley
    <4>EIP: 0060:[<d081621c>] EFLAGS: 00010246 CPU: 16
    <4>EIP is at ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe]
    <4>EAX: c7628820 EBX: 00000007 ECX: 00000000 EDX: 00000000
    <4>ESI: 00000008 EDI: c6882180 EBP: dfc6b000 ESP: ced95c48
    <4> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    <0>Process swapper (pid: 0, ti=ced94000 task=ced73bd0 task.ti=ced94000)
    <0>Stack:
    <4> cbec7418 c779e0d8 c77cc888 c77cc8a8 0903010a 00000000 c77c0008 00000002
    <4><0> cd4997c0 00000010 dfc6b000 00000000 d0d176c9 c77cc8d8 c6882180 cbec7318
    <4><0> 00000004 00000004 cbec7230 cbec7110 00000000 cbec70c0 c779e000 00000002
    <0>Call Trace:
    <4> [<d0d176c9>] ? 0xd0d176c9
    <4> [<d0d18a4d>] ? 0xd0d18a4d
    <4> [<411e243e>] ? dev_hard_start_xmit+0x218/0x2d7
    <4> [<411f03d7>] ? sch_direct_xmit+0x4b/0x114
    <4> [<411f056a>] ? __qdisc_run+0xca/0xe0
    <4> [<411e28b0>] ? dev_queue_xmit+0x2d1/0x3d0
    <4> [<411e8120>] ? neigh_resolve_output+0x1c5/0x20f
    <4> [<411e94a1>] ? neigh_update+0x29c/0x330
    <4> [<4121cf29>] ? arp_process+0x49c/0x4cd
    <4> [<411f80c9>] ? nf_hook_slow+0x3f/0xac
    <4> [<4121ca8d>] ? arp_process+0x0/0x4cd
    <4> [<4121ca8d>] ? arp_process+0x0/0x4cd
    <4> [<4121c6d5>] ? T.901+0x38/0x3b
    <4> [<4121c918>] ? arp_rcv+0xa3/0xb4
    <4> [<4121ca8d>] ? arp_process+0x0/0x4cd
    <4> [<411e1173>] ? __netif_receive_skb+0x32b/0x346
    <4> [<411e19e1>] ? netif_receive_skb+0x5a/0x5f
    <4> [<411e1ea9>] ? napi_skb_finish+0x1b/0x30
    <4> [<d0816eb4>] ? ixgbe_xmit_frame_ring+0x1564/0x2260 [ixgbe]
    <4> [<41013468>] ? lapic_next_event+0x13/0x16
    <4> [<410429b2>] ? clockevents_program_event+0xd2/0xe4
    <4> [<411e1b03>] ? net_rx_action+0x55/0x127
    <4> [<4102da1a>] ? __do_softirq+0x77/0xeb
    <4> [<4102dab1>] ? do_softirq+0x23/0x27
    <4> [<41003a67>] ? do_IRQ+0x7d/0x8e
    <4> [<41002a69>] ? common_interrupt+0x29/0x30
    <4> [<41007bcf>] ? mwait_idle+0x48/0x4d
    <4> [<4100193b>] ? cpu_idle+0x37/0x4c
    <0>Code: df 09 d7 0f 94 c2 0f b6 d2 e9 e7 fb ff ff 31 db 31 c0 e9 38
    ff ff ff 80 78 06 06 0f 85 3e fb ff ff 8b 7c 24 38 8b 8f b8 00 00 00
    <0f> b6 51 0d f6 c2 01 0f 85 27 fb ff ff 80 e2 02 75 0d 8b 6c 24
    <0>EIP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] SS:ESP
    
    Signed-off-by: Mukund Jampala <jbmukund@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 180e38dc2e83a549821b942884efab22e807e752
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Thu Dec 6 14:44:59 2012 -0700

    kvm: Fix irqfd resampler list walk
    
    commit 49f8a1a5394d8baee5e56fb71e5cf993c228689a upstream.
    
    Typo for the next pointer means we're walking random data here.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 710c8f51c857395ea1bf708144768b305800789e
Author: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date:   Wed Jan 23 13:59:05 2013 -0500

    drm/radeon: fix a rare case of double kfree
    
    commit 1da80cfa8727abf404fcee44d04743febea54069 upstream.
    
    If one (but not both) allocations of p->chunks[].kpage[]
    in radeon_cs_parser_init fail, the error path will free
    the successfully allocated page, but leave a stale pointer
    value in the kpage[] field. This will later cause a
    double-free when radeon_cs_parser_fini is called.
    This patch fixes the issue by forcing both pointers to NULL
    after kfree in the error path.
    
    The circumstances under which the problem happens are very
    rare. The card must be AGP and the system must run out of
    kmalloc area just at the right time so that one allocation
    succeeds, while the other fails.
    
    Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
    Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c140fec351af47d648819b3ab20e30522e1493c7
Author: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date:   Mon Jan 7 18:21:59 2013 -0500

    drm/radeon: fix error path in kpage allocation
    
    commit 25d8999780f8c1f53928f4a24a09c01550423109 upstream.
    
    Index into chunks[] array doesn't look right.
    
    Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a56040731e5b00081c6d6c26b99e6e257a5d63d7
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Jan 21 23:53:52 2013 +1100

    xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
    
    commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.
    
    When _xfs_buf_find is passed an out of range address, it will fail
    to find a relevant struct xfs_perag and oops with a null
    dereference. This can happen when trying to walk a filesystem with a
    metadata inode that has a partially corrupted extent map (i.e. the
    block number returned is corrupt, but is otherwise intact) and we
    try to read from the corrupted block address.
    
    In this case, just fail the lookup. If it is readahead being issued,
    it will simply not be done, but if it is real read that fails we
    will get an error being reported.  Ideally this case should result
    in an EFSCORRUPTED error being reported, but we cannot return an
    error through xfs_buf_read() or xfs_buf_get() so this lookup failure
    may result in ENOMEM or EIO errors being reported instead.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Cc: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7603fd9328805a5e8ebe66d870e2a1210fde6f4
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Fri Jan 25 10:07:25 2013 +0000

    x86, efi: Set runtime_version to the EFI spec revision
    
    commit 712ba9e9afc4b3d3d6fa81565ca36fe518915c01 upstream.
    
    efi.runtime_version is erroneously being set to the value of the
    vendor's firmware revision instead of that of the implemented EFI
    specification. We can't deduce which EFI functions are available based
    on the revision of the vendor's firmware since the version scheme is
    likely to be unique to each vendor.
    
    What we really need to know is the revision of the implemented EFI
    specification, which is available in the EFI System Table header.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: Seiji Aguchi <seiji.aguchi@hds.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb0cc88edfdf7d038bb15616c9d3b22992de34cf
Author: Nathan Zimmer <nzimmer@sgi.com>
Date:   Tue Jan 8 09:02:43 2013 -0600

    efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
    
    commit b8f2c21db390273c3eaf0e5308faeaeb1e233840 upstream.
    
    Update efi_call_phys_prelog to install an identity mapping of all available
    memory.  This corrects a bug on very large systems with more then 512 GB in
    which bios would not be able to access addresses above not in the mapping.
    
    The result is a crash that looks much like this.
    
    BUG: unable to handle kernel paging request at 000000effd870020
    IP: [<0000000078bce331>] 0x78bce330
    PGD 0
    Oops: 0000 [#1] SMP
    Modules linked in:
    CPU 0
    Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
    RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
    RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
    RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
    RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
    RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
    R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
    R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
    FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
    Stack:
     0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
     0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
     0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
    Call Trace:
     [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
     [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
     [<ffffffff81035946>] ? efi_call4+0x46/0x80
     [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
     [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
     [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
     [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
     [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
     [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
    Code:  Bad RIP value.
    RIP  [<0000000078bce331>] 0x78bce330
     RSP <ffffffff81601d28>
    CR2: 000000effd870020
    ---[ end trace ead828934fef5eab ]---
    
    Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Signed-off-by: Robin Holt <holt@sgi.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8298a286761e2e9b3aa1b088b7e8aef0da45c6c
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Mon Jan 7 22:01:50 2013 +0000

    x86, efi: Fix 32-bit EFI handover protocol entry point
    
    commit f791620fa7517e1045742c475a7f005db9a634b8 upstream.
    
    If the bootloader calls the EFI handover entry point as a standard function
    call, then it'll have a return address on the stack. We need to pop that
    before calling efi_main(), or the arguments will all be out of position on
    the stack.
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23c70dc831ea93fa73b29167cd7ed94147b61386
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Mon Jan 7 21:52:16 2013 +0000

    x86, efi: Fix display detection in EFI boot stub
    
    commit 70a479cbe80296d3113e65cc2f713a5101061daf upstream.
    
    When booting under OVMF we have precisely one GOP device, and it
    implements the ConOut protocol.
    
    We break out of the loop when we look at it... and then promptly abort
    because 'first_gop' never gets set. We should set first_gop *before*
    breaking out of the loop. Yes, it doesn't really mean "first" any more,
    but that doesn't matter. It's only a flag to indicate that a suitable
    GOP was found.
    
    In fact, we'd do just as well to initialise 'width' to zero in this
    function, then just check *that* instead of first_gop. But I'll do the
    minimal fix for now (and for stable@).
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98e1ea492c1cf36ea3b391d9b5161681ee4ea18a
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Thu Jan 3 09:02:37 2013 +0000

    samsung-laptop: Disable on EFI hardware
    
    commit e0094244e41c4d0c7ad69920681972fc45d8ce34 upstream.
    
    It has been reported that running this driver on some Samsung laptops
    with EFI can cause those machines to become bricked as detailed in the
    following report,
    
    	https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    
    There have also been reports of this driver causing Machine Check
    Exceptions on recent EFI-enabled Samsung laptops,
    
    	https://bugzilla.kernel.org/show_bug.cgi?id=47121
    
    So disable it if booting from EFI since this driver relies on
    grovelling around in the BIOS memory map which isn't going to work.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: Corentin Chary <corentincj@iksaif.net>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Steve Langasek <steve.langasek@canonical.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72b56e869fa2c058969e47da101a9e7d319f6062
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Wed Nov 14 09:42:35 2012 +0000

    efi: Make 'efi_enabled' a function to query EFI facilities
    
    commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.
    
    Originally 'efi_enabled' indicated whether a kernel was booted from
    EFI firmware. Over time its semantics have changed, and it now
    indicates whether or not we are booted on an EFI machine with
    bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
    
    The immediate motivation for this patch is the bug report at,
    
        https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    
    which details how running a platform driver on an EFI machine that is
    designed to run under BIOS can cause the machine to become
    bricked. Also, the following report,
    
        https://bugzilla.kernel.org/show_bug.cgi?id=47121
    
    details how running said driver can also cause Machine Check
    Exceptions. Drivers need a new means of detecting whether they're
    running on an EFI machine, as sadly the expression,
    
        if (!efi_enabled)
    
    hasn't been a sufficient condition for quite some time.
    
    Users actually want to query 'efi_enabled' for different reasons -
    what they really want access to is the list of available EFI
    facilities.
    
    For instance, the x86 reboot code needs to know whether it can invoke
    the ResetSystem() function provided by the EFI runtime services, while
    the ACPI OSL code wants to know whether the EFI config tables were
    mapped successfully. There are also checks in some of the platform
    driver code to simply see if they're running on an EFI machine (which
    would make it a bad idea to do BIOS-y things).
    
    This patch is a prereq for the samsung-laptop fix patch.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Corentin Chary <corentincj@iksaif.net>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Steve Langasek <steve.langasek@canonical.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9f93c7550b62939f250fad55b111637b0f66bc8
Author: Alan Cox <alan@linux.intel.com>
Date:   Thu Nov 15 13:06:22 2012 +0000

    x86/msr: Add capabilities check
    
    commit c903f0456bc69176912dee6dd25c6a66ee1aed00 upstream.
    
    At the moment the MSR driver only relies upon file system
    checks. This means that anything as root with any capability set
    can write to MSRs. Historically that wasn't very interesting but
    on modern processors the MSRs are such that writing to them
    provides several ways to execute arbitary code in kernel space.
    Sample code and documentation on doing this is circulating and
    MSR attacks are used on Windows 64bit rootkits already.
    
    In the Linux case you still need to be able to open the device
    file so the impact is fairly limited and reduces the security of
    some capability and security model based systems down towards
    that of a generic "root owns the box" setup.
    
    Therefore they should require CAP_SYS_RAWIO to prevent an
    elevation of capabilities. The impact of this is fairly minimal
    on most setups because they don't have heavy use of
    capabilities. Those using SELinux, SMACK or AppArmor rules might
    want to consider if their rulesets on the MSR driver could be
    tighter.
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad843163ebf7846a89e25b8ce8eb4b0fb36cf120
Author: Wang YanQing <udknight@gmail.com>
Date:   Sat Jan 26 15:53:57 2013 +0800

    smp: Fix SMP function call empty cpu mask race
    
    commit f44310b98ddb7f0d06550d73ed67df5865e3eda5 upstream.
    
    I get the following warning every day with v3.7, once or
    twice a day:
    
      [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()
    
    As explained by Linus as well:
    
     |
     | Once we've done the "list_add_rcu()" to add it to the
     | queue, we can have (another) IPI to the target CPU that can
     | now see it and clear the mask.
     |
     | So by the time we get to actually send the IPI, the mask might
     | have been cleared by another IPI.
     |
    
    This patch also fixes a system hang problem, if the data->cpumask
    gets cleared after passing this point:
    
            if (WARN_ONCE(!mask, "empty IPI mask"))
                    return;
    
    then the problem in commit 83d349f35e1a ("x86: don't send an IPI to
    the empty set of CPU's") will happen again.
    
    Signed-off-by: Wang YanQing <udknight@gmail.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: peterz@infradead.org
    Cc: mina86@mina86.org
    Cc: srivatsa.bhat@linux.vnet.ibm.com
    Link: http://lkml.kernel.org/r/20130126075357.GA3205@udknight
    [ Tidied up the changelog and the comment in the code. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82a16eebfb3558dc3bdd2dcf15acae1a05155092
Author: Nicholas Santos <nicholas.santos@gmail.com>
Date:   Fri Dec 28 22:07:02 2012 -0500

    HID: usbhid: quirk for Formosa IR receiver
    
    commit 320cde19a4e8f122b19d2df7a5c00636e11ca3fb upstream.
    
    Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver
    [IR605A/Q] to hid-ids.h and hid-quirks.c.  This IR receiver causes about a 10
    second timeout when the usbhid driver attempts to initialze the device.  Adding
    this device to the quirks list with HID_QUIRK_NO_INIT_REPORTS removes the
    delay.
    
    Signed-off-by: Nicholas Santos <nicholas.santos@gmail.com>
    [jkosina@suse.cz: fix ordering]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21c8846acf632c6497311f9d5946166d079ce4f4
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Jan 30 13:04:10 2013 -0500

    NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session
    
    commit c489ee290bdbbace6bb63ebe6ebd4dd605819495 upstream.
    
    NFS4ERR_DELAY is a legal reply when we call DESTROY_SESSION. It
    usually means that the server is busy handling an unfinished RPC
    request. Just sleep for a second and then retry.
    We also need to be able to handle the NFS4ERR_BACK_CHAN_BUSY return
    value. If the NFS server has outstanding callbacks, we just want to
    similarly sleep & retry.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55eca33b3b4d17faf8fa428a99fb3e95b4ce76fe
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jan 18 23:01:43 2013 -0500

    NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery
    
    commit 65436ec0c8e344d9b23302b686e418f2a7b7cf7b upstream.
    
    We do need to start the lease recovery thread prior to waiting for the
    client initialisation to complete in NFSv4.1.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Chuck Lever <chuck.lever@oracle.com>
    Cc: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 742f4ab5acf285f74a86462aa2a78daf1a430ae8
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jan 18 22:56:23 2013 -0500

    NFSv4: Fix NFSv4 trunking discovery
    
    commit 202c312dba7d95b96493b412c606163a0cd83984 upstream.
    
    If walking the list in nfs4[01]_walk_client_list fails, then the most
    likely explanation is that the server dropped the clientid before we
    actually managed to confirm it. As long as our nfs_client is the very
    last one in the list to be tested, the caller can be assured that this
    is the case when the final return value is NFS4ERR_STALE_CLIENTID.
    
    Reported-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 607f8acb842d81ab83895d458dacbcbf62729d7d
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jan 18 22:41:53 2013 -0500

    NFSv4: Fix NFSv4 reference counting for trunked sessions
    
    commit 4ae19c2dd713edb7b8ad3d4ab9d234ed5dcb6b98 upstream.
    
    The reference counting in nfs4_init_client assumes wongly that it
    is safe for nfs4_discover_server_trunking() to return a pointer to a
    nfs_client prior to bumping the reference count.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Chuck Lever <chuck.lever@oracle.com>
    Cc: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8900c903a85433be3b66fbbf0e15ff6bba0678b0
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Jan 22 00:17:06 2013 -0500

    NFS: Don't silently fail setattr() requests on mountpoints
    
    commit ab225417825963b6dc66be7ea80f94ac1378dfdf upstream.
    
    Ensure that any setattr and getattr requests for junctions and/or
    mountpoints are sent to the server. Ever since commit
    0ec26fd0698 (vfs: automount should ignore LOOKUP_FOLLOW), we have
    silently dropped any setattr requests to a server-side mountpoint.
    For referrals, we have silently dropped both getattr and setattr
    requests.
    
    This patch restores the original behaviour for setattr on mountpoints,
    and tries to do the same for referrals, provided that we have a
    filehandle...
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e31c4ce31822e555047981b6dd0b2e54dd2224f1
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Jan 16 15:05:44 2013 -0500

    NFS: Fix error reporting in nfs_xdev_mount
    
    commit dee972b967ae111ad5705733de17a3bfc4632311 upstream.
    
    Currently, nfs_xdev_mount converts all errors from clone_server() to
    ENOMEM, which can then leak to userspace (for instance to 'mount'). Fix that.
    Also ensure that if nfs_fs_mount_common() returns an error, we
    don't dprintk(0)...
    
    The regression originated in commit 3d176e3fe4f6dc379b252bf43e2e146a8f7caf01
    (NFS: Use nfs_fs_mount_common() for xdev mounts)
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c57854aa6bc2a4f9461b26b3c1c382c460cbf09
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jan 20 23:50:13 2013 +0100

    iommu/intel: disable DMAR for g4x integrated gfx
    
    commit 9452618e7462181ed9755236803b6719298a13ce upstream.
    
    DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
    So don't bother, but instead disable it by default to allow distros to
    unconditionally enable DMAR support.
    
    v2: Actually wire up the right quirk entry, spotted by Adam Jackson.
    
    Note that according to intel marketing materials only g45 and gm45
    support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by
    now. Still, keep all the other gen4 ids in the quirk table in case the
    marketing stuff confused me again, which would not be the first time.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
    Cc: Adam Jackson <ajax@redhat.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: stable@vger.kernel.org
    Acked-By: David Woodhouse <David.Woodhouse@intel.com>
    Tested-by: stathis <stathis@npcglib.org>
    Tested-by: Mihai Moldovan <ionic@ionic.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Mihai Moldovan <ionic@ionic.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e18ef0a55a00817e7ce7be8b3e0e725a2caaf1f2
Author: Anderson Lizardo <anderson.lizardo@openbossa.org>
Date:   Sun Jan 6 18:28:53 2013 -0400

    Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()
    
    commit 0a9ab9bdb3e891762553f667066190c1d22ad62b upstream.
    
    The length parameter should be sizeof(req->name) - 1 because there is no
    guarantee that string provided by userspace will contain the trailing
    '\0'.
    
    Can be easily reproduced by manually setting req->name to 128 non-zero
    bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
    input subsystem:
    
    $ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
    AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af
    
    ("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
    field in struct hid_device due to overflow.)
    
    Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acce24c5f19b95709c56c83ef19e3dbb65530154
Author: Chris Rattray <crattray@opensource.wolfsonmicro.com>
Date:   Tue Jan 15 13:22:36 2013 +0000

    ASoC: wm2200: correct mixer values and text
    
    commit a80cc734282805e15b5e023751a4d02f7ffbcc91 upstream.
    
    Signed-off-by: Chris Rattray <crattray@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b261ddc2b7f1b5a61e097c8a461df5018fda040d
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu Jan 17 14:15:59 2013 +0900

    ASoC: arizona: Use actual rather than desired BCLK when calculating LRCLK
    
    commit b59e0f82aa350e380142353fbd30706092ba6312 upstream.
    
    Otherwise we'll get the wrong LRCLK if we need to pick a higher BCLK than
    is required.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 629e227b59e5dc27966245258dfbe0fc97d1a936
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Jan 26 10:49:24 2013 +0300

    EDAC: Test correct variable in ->store function
    
    commit 8024c4c0b1057d1cd811fc9c3f88f81de9729fcd upstream.
    
    We're testing for ->show but calling ->store().
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 718a59dc174d0f4ac3c33451f5f1c80882c86198
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 29 18:07:22 2013 +0100

    ALSA: hda - Fix non-snoop page handling
    
    commit 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a upstream.
    
    For non-snoop mode, we fiddle with the page attributes of CORB/RIRB
    and the position buffer, but also the ring buffers.  The problem is
    that the current code blindly assumes that the buffer is contiguous.
    However, the ring buffers may be SG-buffers, thus a wrong vmapped
    address is passed there, leading to Oops.
    
    This patch fixes the handling for SG-buffers.
    
    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=800701
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70f89f5122903ab3bea6b327ce1158dca53ae2eb
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jan 28 05:45:47 2013 +0100

    ALSA: hda - fix inverted internal mic on Acer AOA150/ZG5
    
    commit fcd8f3b1d43c645e291638bc6c80a1c680722869 upstream.
    
    This patch enables internal mic input on the machine.
    
    BugLink: https://bugs.launchpad.net/bugs/1107477
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abe70505d5bbb42ffb090371115c3e82626a0a21
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 23 18:16:24 2013 +0100

    ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880
    
    commit 0712eea349d8e2b6d0e44b94a752d999319027fb upstream.
    
    A Packard-Bell desktop machine gives no proper pin configuration from
    BIOS.  It's almost equivalent with the 6stack+fp standard config, just
    take the existing fixup.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=901846
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abfa0eb0b90f045a2d3b15d8eb2eec9bb9c1c192
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Thu Nov 29 17:04:23 2012 +0100

    ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices
    
    commit d56268fb108c7c21e19933588ca4d94652585183 upstream.
    
    Commit 23caaf19b11e (ALSA: usb-mixer: Add support for Audio Class v2.0)
    forgot to adjust the length check for UAC 2.0 feature unit descriptors.
    This would make the code abort on encountering a feature unit without
    per-channel controls, and thus prevented the driver to work with any
    device having such a unit, such as the RME Babyface or Fireface UCX.
    
    Reported-by: Florian Hanisch <fhanisch@uni-potsdam.de>
    Tested-by: Matthew Robbetts <wingfeathera@gmail.com>
    Tested-by: Michael Beer <beerml@sigma6audio.de>
    Cc: Daniel Mack <daniel@caiaq.de>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 170c873e1406f2a3bf578acdeac7343388dae248
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Jan 20 21:55:22 2013 +0100

    ath9k: allow setting arbitrary antenna masks on AR9003+
    
    commit fea92cbf0850d788683827990670d3968f893327 upstream.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d94d4a502560adec4728003cd616eedbeeaea4bb
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Jan 20 21:55:21 2013 +0100

    ath9k_hw: fix chain swap setting when setting rx chainmask to 5
    
    commit 24171dd92096fc370b195f3f6bdc0798855dc3f9 upstream.
    
    Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
    regardless of what the runtime chainmask is.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94076a8cfd22ee8ab5e299bd3f5f603b60976a6d
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Mon Jan 14 16:56:46 2013 +0100

    ath9k: disable the tasklet before taking the PCU lock
    
    commit 4668cce527acb3bd048c5e6c99b157a14b214671 upstream.
    
    Fixes a reported CPU soft lockup where the tasklet tries to acquire the
    lock and blocks while ath_prepare_reset (holding the lock) waits for it
    to complete.
    
    Reported-by: Robert Shade <robert.shade@gmail.com>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6dfa60488226d35f04b21f760cb17b05481ebe5
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Mon Jan 14 10:50:15 2013 +0100

    ath9k: remove sc->rx.rxbuflock to fix a deadlock
    
    commit 463e3ed3eacc8f47866e5d612bd8ee0bcee5e2f0 upstream.
    
    The commit "ath9k: fix rx flush handling" added a deadlock that happens
    because ath_rx_tasklet is called in a section that has already taken the
    rx buffer lock.
    
    It seems that the only purpose of the rxbuflock was a band-aid fix to the
    reset vs rx tasklet race, which has been properly fixed in the commit
    "ath9k: add a better fix for the rx tasklet vs rx flush race".
    
    Now that the fix is in, we can safely remove the lock to avoid such issues.
    
    Reported-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e945e4c38a922fba6b8780f53c2e45f604a624e6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Jan 9 16:16:56 2013 +0100

    ath9k: fix rx flush handling
    
    commit 4b883f021b9ccf2df3d14425e6e610281fb6a35e upstream.
    
    Right now the rx flush is not doing anything useful on AR9003+, as it only
    works if the buffers in the rx FIFO have not been purged yet, as is done
    by ath_stoprecv.
    
    To fix this, always call ath_flushrecv from within ath_stoprecv before
    the FIFO is emptied, but still after the hw receive path has been stopped.
    
    This ensures that frames received (and ACKed by the hardware) shortly before
    a reset will be seen by the software, which should improve A-MPDU session
    stability.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8cd68aab45c3b4eb16c235dfb86bb8d0e363b96
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Jan 9 16:16:55 2013 +0100

    ath9k: add a better fix for the rx tasklet vs rx flush race
    
    commit 7fc00a3054b70b1794c2d64db703eb467ad0365c upstream.
    
    Ensure that the rx tasklet is no longer running when entering the reset path.
    Also remove the distinction between flush and no-flush frame processing.
    If a frame has been received and ACKed by the hardware, the stack needs to see
    it, so that the BA receive window does not go out of sync.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d15defa2a8600a65690e9a01d996a32f6d5efe47
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Jan 9 16:16:54 2013 +0100

    ath9k: remove the WARN_ON that triggers if generating a beacon fails
    
    commit 3adcf20afb585993ffee24de36d1975f6b26b120 upstream.
    
    During teardown, mac80211 will not return a new beacon. This is normal and
    handled properly in the driver, so there's no need to spam the user with a kernel
    warning here.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 528025c1a9960573a6fd2a20630c578a525c9e06
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Jan 9 16:16:53 2013 +0100

    ath9k: fix double-free bug on beacon generate failure
    
    commit 1adb2e2b5f85023d17eb4f95386a57029df27c88 upstream.
    
    When the next beacon is sent, the ath_buf from the previous run is reused.
    If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
    the skb is freed, leading to a double-free on the next beacon tx attempt,
    resulting in a system crash.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78c9beedca0d9a8c149d23be981fcafc592f4079
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Jan 9 16:16:52 2013 +0100

    ath9k: do not link receive buffers during flush
    
    commit a3dc48e82bb146ef11cf75676c8410c1df29b0c4 upstream.
    
    On AR9300 the rx FIFO needs to be empty during reset to ensure that no
    further DMA activity is generated, otherwise it might lead to memory
    corruption issues.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3bc989042f631e30311de3441995ba14a26ec0f
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Wed Jan 9 16:07:48 2013 +0530

    ath9k_htc: Fix memory leak
    
    commit 0981c3b24ef664f5611008a6e6d0622fac6d892b upstream.
    
    SKBs that are allocated in the HTC layer do not have callbacks
    registered and hence ended up not being freed, Fix this by freeing
    them properly in the TX completion routine.
    
    Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40ebab2dcc6193f35a7c429c58340e1a40ae71c8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 11 14:34:25 2013 +0100

    mac80211: fix FT roaming
    
    commit 1626e0fa740dec8665a973cf2349405cdfeb46dc upstream.
    
    During FT roaming, wpa_supplicant attempts to set the
    key before association. This used to be rejected, but
    as a side effect of my commit 66e67e418908442389d3a9e
    ("mac80211: redesign auth/assoc") the key was accepted
    causing hardware crypto to not be used for it as the
    station isn't added to the driver yet.
    
    It would be possible to accept the key and then add it
    to the driver when the station has been added. However,
    this may run into issues with drivers using the state-
    based station adding if they accept the key only after
    association like it used to be.
    
    For now, revert to the behaviour from before the auth
    and assoc change.
    
    Reported-by: Cédric Debarge <cedric.debarge@acksys.fr>
    Tested-by: Cédric Debarge <cedric.debarge@acksys.fr>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e30437e717dc55b3edfb9bfad46637005c71ed0
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Dec 20 14:41:18 2012 +0100

    mac80211: synchronize scan off/on-channel and PS states
    
    commit aacde9ee45225f7e0b90960f479aef83c66bfdc0 upstream.
    
    Since:
    
    commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
    Author: Ben Greear <greearb@candelatech.com>
    Date:   Fri Feb 4 11:54:17 2011 -0800
    
        mac80211: Optimize scans on current operating channel.
    
    we do not disable PS while going back to operational channel (on
    ieee80211_scan_state_suspend) and deffer that until scan finish.
    But since we are allowed to send frames, we can send a frame to AP
    without PM bit set, so disable PS on AP side. Then when we switch
    to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
    Hence we are off-channel with PS disabled, frames are not buffered
    by AP.
    
    To fix remove offchannel_ps_disable argument and always enable PS when
    going off-channel and disable it when going on-channel, like it was
    before.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Tested-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99e73c1ae687136241d8e46d3ed7c7e67cda20e1
Author: Jonathan Brassow <jbrassow@redhat.com>
Date:   Tue Jan 22 21:42:18 2013 -0600

    DM-RAID: Fix RAID10's check for sufficient redundancy
    
    commit 55ebbb59c1c6eb1b040f62b8c4ae0b724de6e55a upstream.
    
    Before attempting to activate a RAID array, it is checked for sufficient
    redundancy.  That is, we make sure that there are not too many failed
    devices - or devices specified for rebuild - to undermine our ability to
    activate the array.  The current code performs this check twice - once to
    ensure there were not too many devices specified for rebuild by the user
    ('validate_rebuild_devices') and again after possibly experiencing a failure
    to read the superblock ('analyse_superblocks').  Neither of these checks are
    sufficient.  The first check is done properly but with insufficient
    information about the possible failure state of the devices to make a good
    determination if the array can be activated.  The second check is simply
    done wrong in the case of RAID10 because it doesn't account for the
    independence of the stripes (i.e. mirror sets).  The solution is to use the
    properly written check ('validate_rebuild_devices'), but perform the check
    after the superblocks have been read and we know which devices have failed.
    This gives us one check instead of two and performs it in a location where
    it can be done right.
    
    Only RAID10 was affected and it was affected in the following ways:
    - the code did not properly catch the condition where a user specified
      a device for rebuild that already had a failed device in the same mirror
      set.  (This condition would, however, be caught at a deeper level in MD.)
    - the code triggers a false positive and denies activation when devices in
      independent mirror sets have failed - counting the failures as though they
      were all in the same set.
    
    The most likely place this error was introduced (or this patch should have
    been included) is in commit 4ec1e369 - first introduced in v3.7-rc1.
    Consequently this fix should also go in v3.7.y, however there is a
    small conflict on the .version in raid_target, so I'll submit a
    separate patch to -stable.
    
    Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f564fa15c6c1959953c98ddd834bfc81dad5b937
Author: Piotr Haber <phaber@broadcom.com>
Date:   Wed Nov 28 21:44:05 2012 +0100

    brcmsmac: handle packet drop during transmit correctly
    
    commit c4dea35e34f5f46e1701156153a09cce429d1ea9 upstream.
    
    The .tx() callback function can drop packets when there is no
    space in the DMA fifo. Propagate that information to caller
    and make sure the freed sk_buff reference is not accessed.
    
    Reviewed-by: Arend van Spriel <arend@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Signed-off-by: Piotr Haber <phaber@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61fbed9efda34521b09aac5042db6a31c69d264e
Author: Piotr Haber <phaber@broadcom.com>
Date:   Thu Jan 10 11:20:48 2013 +0100

    brcmsmac: increase timer reference count for new timers only
    
    commit a1fe52801a992e590cdaee2fb47a94bac9b5da90 upstream.
    
    On hardware reintialization reference count of
    already existing timers would be increased again.
    This leads to problems on module unloading.
    
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Reviewed-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: Piotr Haber <phaber@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8bbc125c8bd43393d9313272ffedf8368a2178f
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Jan 16 11:45:15 2013 +0100

    iwlegacy: fix IBSS cleanup
    
    commit fa4cffcba9e13798ed7c6b8526b91b1631ecb53e upstream.
    
    We do not correctly change interface type when switching from
    IBSS mode to STA mode, that results in microcode errors.
    
    Resolves:
    https://bugzilla.redhat.com/show_bug.cgi?id=886946
    
    Reported-by: Jaroslav Skarvada <jskarvad@redhat.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa755dd2ab5c0bf2a049ed375808befaf9947a3e
Author: Avinash Patil <patila@marvell.com>
Date:   Mon Jan 21 21:04:10 2013 -0800

    mwifiex: fix typo in PCIe adapter NULL check
    
    commit 83f0c6d1f502bd75bb4a9e31e8d64e59c6894ad1 upstream.
    
    Add missing "!" as we are supposed to check "!card->adapter"
    in PCIe suspend handler.
    
    Signed-off-by: Avinash Patil <patila@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Reviewed-by: Sergey V. <sftp.mtuci@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b51a7f7c8c4ddd89850dcd8b8b7cf9c1d6b376c7
Author: Amitkumar Karwar <akarwar@marvell.com>
Date:   Tue Jan 8 17:53:10 2013 -0800

    mwifiex: update config_bands during infra association
    
    commit d7b9c5204e9c6810a20d509ee47bc70419096e59 upstream.
    
    Currently "adapter->config_bands" is updated during infra
    association only if channel is provided by user in "iw connect"
    command. config_bands is used while preparing association
    request to calculate supported rates by intersecting our rates
    with the rates advertised by AP.
    
    There is corner case in which we include zero rates in
    supported rates TLV based on previous IBSS network history,
    which leads to association failure.
    
    This patch fixes the problem by correctly updating config_bands.
    
    Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a9d24b881440a559798eb05a3df815e0bcc4bdb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state
    
    commit 4518f611ba21ba165ea3714055938a8984a44ff9 upstream.
    
    Useful for statistics or on overflowing bug reports to keep things all
    lined up.
    
    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 36ce28cb51131636255b03c6ca3fc785f2cd3d84
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jan 20 16:33:32 2013 +0000

    drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits
    
    commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream.
    
    On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1,
    the hardware can not program the scanline values. Those scanline values
    then control when the signal is sent from the display engine to the render
    ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB
    invalidations must be performed explicitly through the appropriate bits
    being set in PIPE_CONTROL.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 924782ca0427bc09e9ad5cc282fbd11588996626
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jan 20 16:11:20 2013 +0000

    drm/i915: Disable AsyncFlip performance optimisations
    
    commit 1c8c38c588ea91f8deeae21284840459d1bb58e3 upstream.
    
    This is a required workarounds for all products, especially on gen6+
    where it causes the command streamer to fail to parse instructions
    following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising
    between the GPU and the display engines, and so this bit being unset may
    cause hangs.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    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 b85ddc2da7cc0827c0b3c3073b88730f5c1f20c9
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Mon Jan 21 16:48:07 2013 +0100

    s390/thp: implement pmdp_set_wrprotect()
    
    commit be3286507dab888d4aad9f91fd6ff5202b24cd5b upstream.
    
    On s390, an architecture-specific implementation of the function
    pmdp_set_wrprotect() is missing and the generic version is currently
    being used. The generic version does not flush the tlb as it would be
    needed on s390 when modifying an active pmd, which can lead to subtle
    tlb errors on s390 when using transparent hugepages.
    
    This patch adds an s390-specific implementation of pmdp_set_wrprotect()
    including the missing tlb flush.
    
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2698f16a24e6ec48de944f00aef812f19247af60
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 23 13:56:18 2013 +0100

    xfs: Fix possible use-after-free with AIO
    
    commit 4b05d09c18d9aa62d2e7fb4b057f54e5a38963f5 upstream.
    
    Running AIO is pinning inode in memory using file reference. Once AIO
    is completed using aio_complete(), file reference is put and inode can
    be freed from memory. So we have to be sure that calling aio_complete()
    is the last thing we do with the inode.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    CC: xfs@oss.sgi.com
    CC: Ben Myers <bpm@sgi.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 943924faea21e0d9e5fd2bd34e6c32c62bef4a1a
Author: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Date:   Thu Jan 24 13:17:53 2013 -0600

    IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround
    
    commit 318fe782539c4150d1b8e4e6c9dc3a896512cb8a upstream.
    
    The IOMMU may stop processing page translations due to a perceived lack
    of credits for writing upstream peripheral page service request (PPR)
    or event logs. If the L2B miscellaneous clock gating feature is enabled
    the IOMMU does not properly register credits after the log request has
    completed, leading to a potential system hang.
    
    BIOSes are supposed to disable L2B micellaneous clock gating by setting
    L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
    patch corrects that for those which do not enable this workaround.
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18c8e4998fc956bb6b22e760639e83575763e3b8
Author: xueminsu <xuemin.su@intel.com>
Date:   Tue Jan 22 22:16:53 2013 +0800

    radeon_display: Use pointer return error codes
    
    commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.
    
    drm_mode_addfb() expects fb_create return error code
    instead of NULL.
    
    Signed-off-by: xueminsu <xuemin.su@intel.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45bced10746efaccd4d3505a169976ee4c5f2a5d
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Mon Jan 21 15:50:03 2013 -0500

    drm/radeon: fix cursor corruption on DCE6 and newer
    
    commit e521a29014794d139cca46396d1af8faf1295a26 upstream.
    
    Aruba and newer gpu does not need the avivo cursor work around,
    quite the opposite this work around lead to corruption.
    
    agd5f: check DCE6 rather than ARUBA since the issue is DCE
    version specific rather than family specific.
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39780ccc9634b5cf07e4f136ff41e6767db24bd3
Author: Szymon Janc <szymon.janc@tieto.com>
Date:   Tue Dec 11 08:51:19 2012 +0100

    Bluetooth: Fix sending HCI commands after reset
    
    commit dbccd791a3fbbdac12c33834b73beff3984988e9 upstream.
    
    After sending reset command wait for its command complete event before
    sending next command. Some chips sends CC event for command received
    before reset if reset was send before chip replied with CC.
    
    This is also required by specification that host shall not send
    additional HCI commands before receiving CC for reset.
    
    < HCI Command: Reset (0x03|0x0003) plen 0                              [hci0] 18.404612
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.405850
          Write Extended Inquiry Response (0x03|0x0052) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.406079
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.407864
          Reset (0x03|0x0003) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.408062
    > HCI Event: Command Complete (0x0e) plen 12                           [hci0] 18.408835
    
    Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
    Acked-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc20d0c8afdfccf30e24b4ab2055059c63152ed
Author: Linus Walleij <linus.walleij@stericsson.com>
Date:   Wed Jan 2 14:40:14 2013 +0100

    mfd: tc3589x: Use simple irqdomain
    
    commit 1f0529b4d80ad02df637be67ed4f82e93b8db32f upstream.
    
    This fixes a regression in the TC3589x driver introduced in
    commit 15e27b1088245a2de3b7d09d39cd209212eb16af
    "mfd: Provide the tc3589x with its own IRQ domain"
    
    If a system with a TC3589x expander is booted and a base
    IRQ is passed from platform data, a legacy domain will
    be used. However, since the Ux500 is now switched to use
    SPARSE_IRQ, no descriptors get allocated on-the-fly,
    and we get a crash.
    
    Fix this by switching to using the simple irqdomain that
    will handle this uniformly and also allocates descriptors
    explicitly.
    
    Also fix two small whitespace errors in the vicinity while
    we're at it.
    
    Acked-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e5c3e9345afb0c648735c0081dbc79844e7e175
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jan 4 17:44:15 2013 +0000

    ARM: virt: simplify __hyp_stub_install epilog
    
    commit d01723479e6a6c70c83295f7847477a016d5e14a upstream.
    
    __hyp_stub_install duplicates quite a bit of safe_svcmode_maskall
    by forcing the CPU back to SVC. This is unnecessary, as
    safe_svcmode_maskall is called just after.
    
    Furthermore, the way we build SPSR_hyp is buggy as we fail to mask
    the interrupts, leading to interesting behaviours on TC2 + UEFI.
    
    The fix is to simply remove this code and rely on safe_svcmode_maskall
    to do the right thing.
    
    Reviewed-by: Dave Martin <dave.martin@linaro.org>
    Reported-by: Harry Liebel <harry.liebel@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ea563f6289e1c40b56bbb785964b584f3bbf015
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jan 4 17:44:14 2013 +0000

    ARM: virt: boot secondary CPUs through the right entry point
    
    commit 6e484be1ccca3ea495db45900fd42aac8d49d754 upstream.
    
    Secondary CPUs should use the __hyp_stub_install_secondary entry
    point, so boot mode inconsistencies can be detected.
    
    Acked-by: Dave Martin <dave.martin@linaro.org>
    Reported-by: Ian Molton <ian.molton@collabora.co.uk>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a20f49d70254c3ebf687d430bc079d295d4900d
Author: Dave Martin <dave.martin@linaro.org>
Date:   Fri Nov 30 11:56:05 2012 +0000

    ARM: virt: Avoid bx instruction for compatibility with <=ARMv4
    
    commit a4a12e008e292a81d312659529b71be2026ab355 upstream.
    
    Non-T variants of ARMv4 do not support the bx instruction.
    
    However, __hyp_stub_install is always called from the same
    instruction set used to build the bulk of the kernel, so bx should
    not be necessary.
    
    This patch uses the traditional "mov pc" instead of bx.
    
    Signed-off-by: Dave Martin <dave.martin@linaro.org>
    [will: fixed up remaining bx instruction]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53651f307e0dac429b7725622240e287716348c1
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Jan 15 18:51:32 2013 +0100

    ARM: 7628/1: head.S: map one extra section for the ATAG/DTB area
    
    commit 6f16f4998f98e42e3f2dedf663cfb691ff0324af upstream.
    
    We currently use a temporary 1MB section aligned to a 1MB boundary for
    mapping the provided device tree until the final page table is created.
    However, if the device tree happens to cross that 1MB boundary, the end
    of it remains unmapped and the kernel crashes when it attempts to access
    it.  Given no restriction on the location of that DTB, it could end up
    with only a few bytes mapped at the end of a section.
    
    Solve this issue by mapping two consecutive sections.
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
    Tested-by: Tomasz Figa <t.figa@samsung.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db1859df589b01a72f676fc348ab800023dedffa
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Mon Jan 14 19:50:42 2013 +0100

    ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone
    
    commit 568dca15aa2a0f4ddee255894ec393a159f13147 upstream.
    
    Patrik Kluba reports that the preempt count becomes invalid due
    to the preempt_enable() call being unbalanced with a
    preempt_disable() call in the vfp assembly routines. This happens
    because preempt_enable() and preempt_disable() update preempt
    counts under PREEMPT_COUNT=y but the vfp assembly routines do so
    under PREEMPT=y. In a configuration where PREEMPT=n and
    DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable()
    call in VFP_bounce() keeps subtracting from the preempt count
    until it goes negative.
    
    Fix this by always using PREEMPT_COUNT to decided when to update
    preempt counts in the ARM assembly code.
    
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Reported-by: Patrik Kluba <pkluba@dension.com>
    Tested-by: Patrik Kluba <pkluba@dension.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cb11705f9c9e8445e604a54a19e84b63b4c6e7a
Author: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Date:   Wed Jan 16 15:49:53 2013 -0800

    ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
    
    commit b86dc0d8c12bbb9fed3f392c284bdc7114ce00c1 upstream.
    
    We are using S3C_EINT(4) instead of S3C_EINT(5).
    
    Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 940333a9183a3c06f19fa03e1456cf1fd04ff2b7
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date:   Sun Dec 23 18:07:49 2012 +0000

    ARM: at91: rm9200: remake the BGA as default version
    
    commit 36224d0fe0f34cdde66a381708853ebadeac799c upstream.
    
    Make BGA as the default version as we are supposed to just have
    to specify when we use the PQFP version.
    
    Issue was existing since commit:
    3e90772 (ARM: at91: fix at91rm9200 soc subtype handling).
    
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eafa2e083e35851e8d4137f8252765205e281b7c
Author: Luciano Coelho <coelho@ti.com>
Date:   Mon Jan 21 13:14:12 2013 +0200

    ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport
    
    commit 7662a9c60fee25d7234da4be6d8eab2b2ac88448 upstream.
    
    Add the UART2 muxing data to the board file (this used to be,
    erroneously, done in the bootloader).
    
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1a8682defbc9fab5c34afa3ae374468aad40dcc
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Jan 19 11:05:57 2013 +0000

    ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem
    
    commit 15653371c67c3fbe359ae37b720639dd4c7b42c5 upstream.
    
    Subhash Jadavani reported this partial backtrace:
      Now consider this call stack from MMC block driver (this is on the ARMv7
      based board):
    
      [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
      [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
      [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114)
    
    This is caused by incrementing the struct page pointer, and running off
    the end of the sparsemem page array.  Fix this by incrementing by pfn
    instead, and convert the pfn to a struct page.
    
    Suggested-by: James Bottomley <JBottomley@Parallels.com>
    Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7d0c921a6487dca4a0bafb02a9925001df7f3ad
Author: Tiejun Chen <tiejun.chen@windriver.com>
Date:   Sun Jan 6 00:49:34 2013 +0000

    powerpc/book3e: Disable interrupt after preempt_schedule_irq
    
    commit 572177d7c77db1981ba2563e01478126482c43bc upstream.
    
    In preempt case current arch_local_irq_restore() from
    preempt_schedule_irq() may enable hard interrupt but we really
    should disable interrupts when we return from the interrupt,
    and so that we don't get interrupted after loading SRR0/1.
    
    Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 398fdc67c92fdcffc11588ced695c2f212b33e8c
Author: Alexander Graf <agraf@suse.de>
Date:   Thu Jan 17 13:50:25 2013 +0100

    KVM: PPC: Emulate dcbf
    
    commit d3286144c92ec876da9e30320afa875699b7e0f1 upstream.
    
    Guests can trigger MMIO exits using dcbf. Since we don't emulate cache
    incoherent MMIO, just do nothing and move on.
    
    Reported-by: Ben Collins <ben.c@servergy.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>
    Tested-by: Ben Collins <ben.c@servergy.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8ea1c8ac10cc7cfa8f175086158c987daad3653
Author: Cong Ding <dinggnu@gmail.com>
Date:   Tue Jan 22 19:20:58 2013 -0500

    fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
    
    commit 10b8c7dff5d3633b69e77f57d404dab54ead3787 upstream.
    
    When it goes to error through line 144, the memory allocated to *devname is
    not freed, and the caller doesn't free it either in line 250. So we free the
    memroy of *devname in function cifs_compose_mount_options() when it goes to
    error.
    
    Signed-off-by: Cong Ding <dinggnu@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c53238c5954ec36649969e92e138db2a65662c7a
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Fri Jan 18 09:32:41 2013 +0100

    can: pch_can: fix invalid error codes
    
    commit ee50e135aeb048b90fab662e661c58b67341830b upstream.
    
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e46bfb5f56c9b2e6c4ac3ee729a0cb8f88ba674
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Fri Jan 18 09:32:40 2013 +0100

    can: ti_hecc: fix invalid error codes
    
    commit 71088c4bd9b8f8cbffb0e66f2abc14297e4b2ca8 upstream.
    
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Cc: Anant Gole <anantgole@ti.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd4f0f5ac95f054fcdab235e3e01481e906e25aa
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Fri Jan 18 09:32:39 2013 +0100

    can: c_can: fix invalid error codes
    
    commit 6ea45886865c1abb01bb861f7f6bdd5d0f398cb3 upstream.
    
    Errors in CAN protocol (location) are reported in data[3] of the can
    frame instead of data[2].
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>