- 11 Feb, 2013 7 commits
-
-
Alex Deucher authored
commit f7eb9730 upstream. Need to adjust the backend map depending on which RB is enabled. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=892233 Reported-by:
Mikko Tiihonen <mikko.tiihonen@iki.fi> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christopher Staite authored
commit bb588820 upstream. Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case. Signed-off-by:
Christopher Staite <chris@yourdreamnet.co.uk> Signed-off-by:
-
Alex Deucher authored
commit 9200ee49 upstream. vbios says external TMDS while the board is actually internal TMDS. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60037 Signed-off-by:
-
Alex Deucher authored
commit 674a16f2 upstream. Newer versions of mesa emit this. Signed-off-by:
-
Alex Deucher authored
commit ed39fadd upstream. Some chips seem to need a little delay after blacking out the MC before the requests actually stop. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 https://bugs.freedesktop.org/show_bug.cgi?id=57567 Signed-off-by:
-
YOSHIFUJI Hideaki authored
commit 7810cc1e upstream. digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer(). Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Aneesh Kumar K.V authored
commit eda8eebd upstream. The ASM version of hash computation function was truncating the upper bit. Make the ASM version similar to hpt_hash function. Remove masking vsid bits. Without this patch, we observed hang during bootup due to not satisfying page fault request correctly. The fault handler used wrong hash values to update the HPTE. Hence we kept looping with page fault. hash_page(ea=000001003e260008, access=203, trap=300 ip=3fff91787134 dsisr 42000000 The computed value of hash 000000000f22f390 update: avpnv=4003e46054003e00, hash=000000000722f390, f=80000006, psize: 2 ... BenH: The over-masking has been there for ever but only hurts with the new 64T support introduced in 3.7 Reported-by:
Mike Qiu <qiudayu@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Tested-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
- 04 Feb, 2013 33 commits
-
-
Greg Kroah-Hartman authored
-
Pablo Neira Ayuso authored
commit 4610476d 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:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
CAI Qian authored
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 cce89f4f ('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:
-
Jani Nikula authored
commit b5144075 upstream. We stopped reading FORCEWAKE for posting reads in commit 8dee3eea 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:
-
Jesper Juhl authored
commit 1310b955 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:
-
Jan Engelhardt authored
commit 5b76c494 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 authored
commit 1e47ee83 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:
-
Eric Dumazet authored
commit 2727de76 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:
-
Vitaly E. Lavrov authored
commit 665e205c 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 authored
commit 09181842 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:
-
Vitaly E. Lavrov authored
commit 32263dd1 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:
-
Pablo Neira Ayuso authored
commit 757ae316 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:
-
Pablo Neira Ayuso authored
commit 10db9069 upstream. Florian Westphal reported that the removal of the NOTRACK target (96550501 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 authored
commit e035edd1 upstream. In (0c36b48b 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:
-
Bob Hockney authored
commit 0c36b48b 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:
-
Nicholas Bellinger authored
This is to fix a regression that only affect the stable (not for the mainline) that the stable commit fdf9d862 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:
-
Dave Chinner authored
[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 f661f1e0 and 7e18530b .] 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:
-
H. Peter Anvin authored
commit e43b3cec 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>
-
Haibo Xi authored
commit 97cf00e9 upstream. Commit b836c99f (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:
-
Mukund Jampala authored
commit c6f40899 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:
-
Alex Williamson authored
commit 49f8a1a5 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:
-
Ilija Hadzic authored
commit 1da80cfa 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:
-
Ilija Hadzic authored
commit 25d89997 upstream. Index into chunks[] array doesn't look right. Signed-off-by:
-
Dave Chinner authored
commit eb178619 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:
Brian Foster <bfoster@redhat.com> Reviewed-by:
-
Matt Fleming authored
commit 712ba9e9 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:
-
Nathan Zimmer authored
commit b8f2c21d 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:
-
David Woodhouse authored
commit f791620f 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:
-
David Woodhouse authored
commit 70a479cb 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:
-
Matt Fleming authored
commit e0094244 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 authored
commit 83e68189 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:
-
Alan Cox authored
commit c903f045 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:
-
Wang YanQing authored
commit f44310b9 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 83d349f3 ("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:
-
Nicholas Santos authored
commit 320cde19 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:
-
