- 20 Feb, 2012 4 commits
-
-
Nikolaus Schulz authored
commit eb2f255b upstream. In order to extract the high byte of the 16-bit word, shift the word to the right, not to the left. Signed-off-by:
Nikolaus Schulz <mail@microschulz.de> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Vetter authored
commit e57b6886 upstream. According to a bug report, it doesn't have one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Jiri Olsa authored
commit 7a0153ee upstream. By adding following objects: bench/mem-memcpy-x86-64-asm.o the x86_64 perf binary ended up with executable stack. The reason was that above object are assembler sourced and is missing the GNU-stack note section. In such case the linker assumes that the final binary should not be restricted at all and mark the stack as RWX. Adding section ".note.GNU-stack" definition to mentioned object, with all flags disabled, thus omiting this object from linker stack flags decision. Problem introduced in: $ git describe ea7872b9 v2.6.37-rc2-19-gea7872b9 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570Reported-by:
Clark Williams <williams@redhat.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.comSigned-off-by:
Jiri Olsa <jolsa@redhat.com> [ committer note: Backported fix to perf/urgent (3.3-rc2+) ] Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Naveen N. Rao authored
commit a4a03fc7 upstream. This patch fixes an issue where perf report shows nan% for certain perf.data files. The below is from a report for a do_fork probe: -nan% sshd [kernel.kallsyms] [k] do_fork -nan% packagekitd [kernel.kallsyms] [k] do_fork -nan% dbus-daemon [kernel.kallsyms] [k] do_fork -nan% bash [kernel.kallsyms] [k] do_fork A git bisect shows commit f3bda2c9 as the cause. However, looking back through the git history, I saw commit 640c03ce which seems to have removed the required initialization for perf_sample->period. The problem only started showing after commit f3bda2c9. The below patch re-introduces the initialization and it fixes the problem for me. With the below patch, for the same perf.data: 73.08% bash [kernel.kallsyms] [k] do_fork 8.97% 11-dhclient [kernel.kallsyms] [k] do_fork 6.41% sshd [kernel.kallsyms] [k] do_fork 3.85% 20-chrony [kernel.kallsyms] [k] do_fork 2.56% sendmail [kernel.kallsyms] [k] do_fork This patch applies over current linux-tip commit 9949284. Problem introduced in: $ git describe 640c03ce v2.6.37-rc3-83-g640c03ce Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Robert Richter <robert.richter@amd.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
- 13 Feb, 2012 36 commits
-
-
Greg Kroah-Hartman authored
-
Eric Dumazet authored
[ Upstream commit d3aaeb38, along with dependent backports of commits: 69cce1d1 9de79c12 218fa90f 580da35a f7e57044 e049f288 ] Gergely Kalman reported crashes in check_peer_redir(). It appears commit f39925db (ipv4: Cache learned redirect information in inetpeer.) added a race, leading to possible NULL ptr dereference. Since we can now change dst neighbour, we should make sure a reader can safely use a neighbour. Add RCU protection to dst neighbour, and make sure check_peer_redir() can be called safely by different cpus in parallel. As neighbours are already freed after one RCU grace period, this patch should not add typical RCU penalty (cache cold effects) Many thanks to Gergely for providing a pretty report pointing to the bug. Reported-by:
Gergely Kalman <synapse@hippy.csoma.elte.hu> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Andreas Herrmann authored
commit a8eb2848 upstream. The driver uses the pstate number from the status register as index in its table of ACPI pstates (powernow_table). This is wrong as this is not a 1-to-1 mapping. For example we can have _PSS information to just utilize Pstate 0 and Pstate 4, ie. powernow-k8: Core Performance Boosting: on. powernow-k8: 0 : pstate 0 (2200 MHz) powernow-k8: 1 : pstate 4 (1400 MHz) In this example the driver's powernow_table has just 2 entries. Using the pstate number (4) as index into this table is just plain wrong. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Andreas Herrmann authored
commit 201bf0f1 upstream. Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of the paranoia check. (assuming that the ACPI Pstate information is correct.) Signed-off-by:
-
Axel Lin authored
commit b5266ea6 upstream. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Rui li authored
commit 1608ea5f upstream. As ZTE have and will use more pid for new products this year, so we need to add some new zte 3g-dongle's pid on option.c , and delete one pid 0x0154 because it use for mass-storage port. Signed-off-by:
Rui li <li.rui27@zte.com.cn> Signed-off-by:
-
Milan Kocian authored
commit 90451e69 upstream. Signed-off-by:
Milan Kocian <milon@wq.cz> Signed-off-by:
-
Jayachandran C authored
commit e4436a7c upstream. The Netlogic XLP SoC's on-chip USB controller appears as a PCI USB device, but does not need the EHCI/OHCI handoff done in usb/host/pci-quirks.c. The pci-quirks.c is enabled for all vendors and devices, and is enabled if USB and PCI are configured. If we do not skip the qurik handling on XLP, the readb() call in ehci_bios_handoff() will cause a crash since byte access is not supported for EHCI registers in XLP. Signed-off-by:
Jayachandran C <jayachandranc@netlogicmicro.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Timo Juhani Lindfors authored
commit 683da59d upstream. ab943a2e (USB: gadget: gadget zero uses new suspend/resume hooks) introduced a copy-paste error where f_loopback.c writes to a variable declared in f_sourcesink.c. This prevents one from creating gadgets that only have a loopback function. Signed-off-by:
Timo Juhani Lindfors <timo.lindfors@iki.fi> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Larry Finger authored
commit 1793bf1d upstream. Add USB ID for SITECOM WLA-1000 V1 001 WLAN Reported-and-tested-by:
Roland Gruber <post@rolandgruber.de> Reported-and-tested-by:
Dario Lucia <dario.lucia@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Pekka Paalanen authored
commit 3589e745 upstream. Asus_oled triggers the following bug on module unloading: usbcore: deregistering interface driver asus-oled BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [<ffffffff8111292b>] sysfs_delete_link+0x30/0x66 Call Trace: [<ffffffff81225373>] device_remove_class_symlinks+0x6b/0x70 [<ffffffff812256a8>] device_del+0x9f/0x1ab [<ffffffff812257c5>] device_unregister+0x11/0x1e [<ffffffffa000cb82>] asus_oled_disconnect+0x4f/0x9e [asus_oled] [<ffffffff81277430>] usb_unbind_interface+0x54/0x103 [<ffffffff812276c4>] __device_release_driver+0xa2/0xeb [<ffffffff81227794>] driver_detach+0x87/0xad [<ffffffff812269e9>] bus_remove_driver+0x91/0xc1 [<ffffffff81227fb4>] driver_unregister+0x66/0x6e [<ffffffff812771ed>] usb_deregister+0xbb/0xc4 [<ffffffffa000ce87>] asus_oled_exit+0x2f/0x31 [asus_oled] [<ffffffff81068365>] sys_delete_module+0x1b8/0x21b [<ffffffff810ae3de>] ? do_munmap+0x2ef/0x313 [<ffffffff813699bb>] system_call_fastpath+0x16/0x1b This is due to an incorrect destruction sequence in asus_oled_exit(). Fix the order, fixes the bug. Tested on an Asus G50V laptop only. Cc: Jakub Schmidtke <sjakub@gmail.com> Signed-off-by:
Pekka Paalanen <pq@iki.fi> Signed-off-by:
-
Pekka Paalanen authored
commit 635032cb upstream. Programming an image was broken, because odev->buf_offs was not advanced for val == 0 in append_values(). This regression was introduced in: commit 1ff12a4a Author: Kevin A. Granade <kevin.granade@gmail.com> Date: Sat Sep 5 01:03:39 2009 -0500 Staging: asus_oled: Cleaned up checkpatch issues. Fix the image processing by special-casing val == 0. I have tested this change on an Asus G50V laptop only. Cc: Jakub Schmidtke <sjakub@gmail.com> Cc: Kevin A. Granade <kevin.granade@gmail.com> Signed-off-by:
-
Roland Dreier authored
commit 9fbc8909 upstream. According to SPC-4, the sense key for commands that are failed with INVALID FIELD IN PARAMETER LIST and INVALID FIELD IN CDB should be ILLEGAL REQUEST (5h) rather than ABORTED COMMAND (Bh). Without this patch, a tcm_loop LUN incorrectly gives: # sg_raw -r 1 -v /dev/sda 3 1 0 0 ff 0 Sense Information: Fixed format, current; Sense key: Aborted Command Additional sense: Invalid field in cdb Raw sense data (in hex): 70 00 0b 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 While a real SCSI disk gives: Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid field in cdb Raw sense data (in hex): 70 00 05 00 00 00 00 18 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 with the main point being that the real disk gives a sense key of ILLEGAL REQUEST (5h). Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Marco Sanvido authored
commit 6816966a upstream. Initiators that aren't the active reservation holder should be able to do a PERSISTENT RESERVE IN command in all cases, so add it to the list of allowed CDBs in core_scsi3_pr_seq_non_holder(). Signed-off-by:
Marco Sanvido <marco@purestorage.com> Signed-off-by:
-
Marco Sanvido authored
commit 9e08e34e upstream. The comments quote the right parts of the spec: * d) Establish a unit attention condition for the * initiator port associated with every I_T nexus * that lost its registration other than the I_T * nexus on which the PERSISTENT RESERVE OUT command * was received, with the additional sense code set * to REGISTRATIONS PREEMPTED. and * e) Establish a unit attention condition for the initiator * port associated with every I_T nexus that lost its * persistent reservation and/or registration, with the * additional sense code set to REGISTRATIONS PREEMPTED; but the actual code accidentally uses ASCQ_2AH_RESERVATIONS_PREEMPTED instead of ASCQ_2AH_REGISTRATIONS_PREEMPTED. Fix this. Signed-off-by:
-
Hugh Dickins authored
commit b9980cdc upstream. Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false, and so triggers some BUGs in Transparent HugePage codepaths. asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x); but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE, VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mel Gorman authored
commit dc908600 upstream. When isolating pages for migration, migration starts at the start of a zone while the free scanner starts at the end of the zone. Migration avoids entering a new zone by never going beyond the free scanned. Unfortunately, in very rare cases nodes can overlap. When this happens, migration isolates pages without the LRU lock held, corrupting lists which will trigger errors in reclaim or during page free such as in the following oops BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450 PGD 1dda554067 PUD 1e1cb58067 PMD 0 Oops: 0000 [#1] SMP CPU 37 Pid: 17088, comm: memcg_process_s Tainted: G X RIP: free_pcppages_bulk+0xcc/0x450 Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0) Call Trace: free_hot_cold_page+0x17e/0x1f0 __pagevec_free+0x90/0xb0 release_pages+0x22a/0x260 pagevec_lru_move_fn+0xf3/0x110 putback_lru_page+0x66/0xe0 unmap_and_move+0x156/0x180 migrate_pages+0x9e/0x1b0 compact_zone+0x1f3/0x2f0 compact_zone_order+0xa2/0xe0 try_to_compact_pages+0xdf/0x110 __alloc_pages_direct_compact+0xee/0x1c0 __alloc_pages_slowpath+0x370/0x830 __alloc_pages_nodemask+0x1b1/0x1c0 alloc_pages_vma+0x9b/0x160 do_huge_pmd_anonymous_page+0x160/0x270 do_page_fault+0x207/0x4c0 page_fault+0x25/0x30 The "X" in the taint flag means that external modules were loaded but but is unrelated to the bug triggering. The real problem was because the PFN layout looks like this Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x01e80000 Movable zone start PFN for each node early_node_map[14] active PFN ranges 0: 0x00000010 -> 0x0000009b 0: 0x00000100 -> 0x0007a1ec 0: 0x0007a354 -> 0x0007a379 0: 0x0007f7ff -> 0x0007f800 0: 0x00100000 -> 0x00680000 1: 0x00680000 -> 0x00e80000 0: 0x00e80000 -> 0x01080000 1: 0x01080000 -> 0x01280000 0: 0x01280000 -> 0x01480000 1: 0x01480000 -> 0x01680000 0: 0x01680000 -> 0x01880000 1: 0x01880000 -> 0x01a80000 0: 0x01a80000 -> 0x01c80000 1: 0x01c80000 -> 0x01e80000 The fix is straight-forward. isolate_migratepages() has to make a similar check to isolate_freepage to ensure that it never isolates pages from a zone it does not hold the LRU lock for. This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x and current mainline. Signed-off-by:
Mel Gorman <mgorman@suse.de> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Russell King authored
commit 025e4ab3 upstream. This fixes a memory-corrupting bug: not only does it cause the warning, but as a result of dropping the refcount to zero, it causes the pcmcia_socket0 device structure to be freed while it still has references, causing slab caches corruption. A fatal oops quickly follows this warning - often even just a 'dmesg' following the warning causes the kernel to oops. While testing suspend/resume on an ARM device with PCMCIA support, and a CF card inserted, I found that after five suspend and resumes, the kernel would complain, and shortly die after with slab corruption. WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50() As the message doesn't give a clue about which kobject, and the built-in debugging in drivers/base/power/main.c happens too late, this was added right before each get_device(): printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount)); and on the 3rd s2ram cycle, the following behaviour observed: On the 3rd suspend/resume cycle: dpm_prepare: c1a0d998 [pcmcia_socket0] 3 dpm_suspend: c1a0d998 [pcmcia_socket0] 3 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3 dpm_resume: c1a0d998 [pcmcia_socket0] 3 dpm_complete: c1a0d998 [pcmcia_socket0] 2 4th: dpm_prepare: c1a0d998 [pcmcia_socket0] 2 dpm_suspend: c1a0d998 [pcmcia_socket0] 2 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2 dpm_resume: c1a0d998 [pcmcia_socket0] 2 dpm_complete: c1a0d998 [pcmcia_socket0] 1 5th: dpm_prepare: c1a0d998 [pcmcia_socket0] 1 dpm_suspend: c1a0d998 [pcmcia_socket0] 1 dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1 dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1 dpm_resume: c1a0d998 [pcmcia_socket0] 1 dpm_complete: c1a0d998 [pcmcia_socket0] 0 ------------[ cut here ]------------ WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50() Modules linked in: ucb1x00_core Backtrace: [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c) [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68) [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28) [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50) [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24) [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20) ... Looking at commit 7b24e798 ("pcmcia: split up central event handler"), the following change was made to cs.c: return 0; } #endif - - send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW); + if (!(skt->state & SOCKET_CARDBUS) && (skt->callback)) + skt->callback->early_resume(skt); return 0; } And the corresponding change in ds.c is from: -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority) -{ - struct pcmcia_socket *s = pcmcia_get_socket(skt); ... - switch (event) { ... - case CS_EVENT_PM_RESUME: - if (verify_cis_cache(skt) != 0) { - dev_dbg(&skt->dev, "cis mismatch - different card\n"); - /* first, remove the card */ - ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH); - mutex_lock(&s->ops_mutex); - destroy_cis_cache(skt); - kfree(skt->fake_cis); - skt->fake_cis = NULL; - s->functions = 0; - mutex_unlock(&s->ops_mutex); - /* now, add the new card */ - ds_event(skt, CS_EVENT_CARD_INSERTION, - CS_EVENT_PRI_LOW); - } - break; ... - } - pcmcia_put_socket(s); - return 0; -} /* ds_event */ to: +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt) +{ + if (!verify_cis_cache(skt)) { + pcmcia_put_socket(skt); + return 0; + } + dev_dbg(&skt->dev, "cis mismatch - different card\n"); + /* first, remove the card */ + pcmcia_bus_remove(skt); + mutex_lock(&skt->ops_mutex); + destroy_cis_cache(skt); + kfree(skt->fake_cis); + skt->fake_cis = NULL; + skt->functions = 0; + mutex_unlock(&skt->ops_mutex); + /* now, add the new card */ + pcmcia_bus_add(skt); + return 0; +} As can be seen, the original function called pcmcia_get_socket() and pcmcia_put_socket() around the guts, whereas the replacement code calls pcmcia_put_socket() only in one path. This creates an imbalance in the refcounting. Testing with pcmcia_put_socket() put removed shows that the bug is gone: dpm_suspend: c1a10998 [pcmcia_socket0] 5 dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5 dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5 dpm_resume: c1a10998 [pcmcia_socket0] 5 dpm_complete: c1a10998 [pcmcia_socket0] 5 Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Susan Gao authored
commit 2b6712b1 upstream. Signed-off-by:
Susan Gao <sgao@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit 43b6cec2 upstream. The second line output mixer has the controls for the line input bypasses in the opposite order. Signed-off-by:
-
Mark Brown authored
commit ee76744c upstream. IN1L/R is routed to both line output mixers, we don't route IN1 to LINEOUT1 and IN2 to LINEOUT2. Signed-off-by:
-
Guenter Roeck authored
commit 585c0fd8 upstream. NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of chip register bits. Check that second set of bits in addition to the first set to detect if fans 3..5 are monitored. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Peter Zijlstra authored
commit df754e6a upstream. It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case: - bin-only modules can cause various instabilities in their and in unrelated kernel code - they are impossible to debug for kernel developers - they also typically do not have the copyright license permission to link to the GPL-ed lockdep code. Suggested-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Hubert Feurstein authored
commit 9f106503 upstream. An error was existing in the saving of CONTRAST_CTR register across suspend/resume. Signed-off-by:
Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
Shirish Pargaonkar authored
commit de47a417 upstream. For null user mounts, do not invoke string length function during session setup. Reported-and-Tested-by:
Chris Clayton <chris2553@googlemail.com> Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Li Wang authored
commit 684a3ff7 upstream. ecryptfs_write() can enter an infinite loop when truncating a file to a size larger than 4G. This only happens on architectures where size_t is represented by 32 bits. This was caused by a size_t overflow due to it incorrectly being used to store the result of a calculation which uses potentially large values of type loff_t. [tyhicks@canonical.com: rewrite subject and commit message] Signed-off-by:
Li Wang <liwang@nudt.edu.cn> Signed-off-by:
Yunchuan Wen <wenyunchuan@kylinos.com.cn> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Eugeni Dodonov authored
commit 07c1e8c1 upstream. We don't need to check 3rd pipe specifically, as it shares PLL with some other one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rodrigo Vivi authored
commit 23bd15ec upstream. TV Out refresh rate was half of the specification for almost all modes. Due to this reason pixel clock was so low for some modes causing flickering screen. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Daniel Vetter authored
commit 097354eb upstream. Otherwise hangcheck spuriously fires when running blitter/bsd-only workloads. Contrary to a similar patch by Ben Widawsky this does not check INSTDONE of the other rings. Chris Wilson implied that in a failure to detect a hang, most likely because INSTDONE was fluctuating. Thus only check ACTHD, which as far as I know is rather reliable. Also, blitter and bsd rings can't launch complex tasks from a single instruction (like 3D_PRIM on the render with complex or even infinite shaders). This fixes spurious gpu hang detection when running tests/gem_hangcheck_forcewake on snb/ivb. Signed-Off-by:
-
Wu Fengguang authored
commit 832afda6 upstream. On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly, so that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled only when the link training is complete and set to "Normal". Tested OK for both hot plug/remove and DPMS on/off. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
Wu Fengguang authored
commit 2deed761 upstream. On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing HDMI audio after DPMS on. CC: Wang Zhenyu <zhenyu.z.wang@intel.com> Signed-off-by:
-
Jan Kara authored
commit 853a0c25 upstream. When we hit EIO while writing LVID, the buffer uptodate bit is cleared. This then results in an anoying warning from mark_buffer_dirty() when we write the buffer again. So just set uptodate flag unconditionally. Reviewed-by:
Namjae Jeon <linkinjeon@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Dave Jones <davej@redhat.com> Signed-off-by:
-
Mark Brown authored
commit f0e8ed85 upstream. Commit 873bd4cb (ASoC: Don't set invalid name string to snd_card->driver field) broke generation of a driver name for all ASoC cards relying on the automatic generation of one. Fix this by using the old default with spaces replaced by underscores. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Chanho Min authored
commit cb297a3e upstream. This issue happens under the following conditions: 1. preemption is off 2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined 3. RT scheduling class 4. SMP system Sequence is as follows: 1.suppose current task is A. start schedule() 2.task A is enqueued pushable task at the entry of schedule() __schedule prev = rq->curr; ... put_prev_task put_prev_task_rt enqueue_pushable_task 4.pick the task B as next task. next = pick_next_task(rq); 3.rq->curr set to task B and context_switch is started. rq->curr = next; 4.At the entry of context_swtich, release this cpu's rq->lock. context_switch prepare_task_switch prepare_lock_switch raw_spin_unlock_irq(&rq->lock); 5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context 6.try_to_wake_up() which called by ISR acquires rq->lock try_to_wake_up ttwu_remote rq = __task_rq_lock(p) ttwu_do_wakeup(rq, p, wake_flags); task_woken_rt 7.push_rt_task picks the task A which is enqueued before. task_woken_rt push_rt_tasks(rq) next_task = pick_next_pushable_task(rq) 8.At find_lock_lowest_rq(), If double_lock_balance() returns 0, lowest_rq can be the remote rq. (But,If preemption is on, double_lock_balance always return 1 and it does't happen.) push_rt_task find_lock_lowest_rq if (double_lock_balance(rq, lowest_rq)).. 9.find_lock_lowest_rq return the available rq. task A is migrated to the remote cpu/rq. push_rt_task ... deactivate_task(rq, next_task, 0); set_task_cpu(next_task, lowest_rq->cpu); activate_task(lowest_rq, next_task, 0); 10. But, task A is on irq context at this cpu. So, task A is scheduled by two cpus at the same time until restore from IRQ. Task A's stack is corrupted. To fix it, don't migrate an RT task if it's still running. Signed-off-by:
Chanho Min <chanho.min@lge.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.comSigned-off-by:
-
Seth Forshee authored
commit 86698c20 upstream. Polling the outputs when the device is suspended can result in erroneous status updates. Disable output polling during suspend to prevent this from happening. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ben Skeggs authored
commit 525895ba upstream. Due to a race it was possible for a fence to be destroyed while another thread was trying to synchronise with it. If this happened in the fallback non-semaphore path, it lead to the following oops due to fence->channel being NULL. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau] *pde = a649c067 SMP Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi] Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1 EIP is at nouveau_fence_update+0xe/0xe0 [nouveau] EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000 ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000) Stack: 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000 Call Trace: [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau] [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau] [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau] [<fa964046>] validate_list+0x176/0x300 [nouveau] [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm] [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau] [<c0406481>] ? die+0x31/0x80 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm] [<c0406481>] ? die+0x31/0x80 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau] [<c0635c7b>] ? file_has_perm+0xcb/0xe0 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm] [<c0564f56>] do_vfs_ioctl+0x86/0x5b0 [<c0406481>] ? die+0x31/0x80 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130 [<c0554f30>] ? fget_light+0x30/0x340 [<c05654ef>] sys_ioctl+0x6f/0x80 [<c099e3a4>] syscall_call+0x7/0xb [<c0406481>] ? die+0x31/0x80 [<c0406481>] ? die+0x31/0x80 Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
