- 15 Jan, 2015 39 commits
-
-
Takashi Iwai authored
commit f62f5eff upstream. The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A codec like another ASUS machine. Reported-and-tested-by:
Dmitry V. Zimin <pfzim@mail.ru> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Andy Lutomirski authored
commit 29fa6825 upstream. paravirt_enabled has the following effects: - Disables the F00F bug workaround warning. There is no F00F bug workaround any more because Linux's standard IDT handling already works around the F00F bug, but the warning still exists. This is only cosmetic, and, in any event, there is no such thing as KVM on a CPU with the F00F bug. - Disables 32-bit APM BIOS detection. On a KVM paravirt system, there should be no APM BIOS anyway. - Disables tboot. I think that the tboot code should check the CPUID hypervisor bit directly if it matters. - paravirt_enabled disables espfix32. espfix32 should *not* be disabled under KVM paravirt. The last point is the purpose of this patch. It fixes a leak of the high 16 bits of the kernel stack address on 32-bit KVM paravirt guests. Fixes CVE-2014-8134. Suggested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Daniel Vetter authored
commit 0b6d24c0 upstream. Apparently stuff works that way on those machines. I agree with Chris' concern that this is a bit risky but imo worth a shot in -next just for fun. Afaics all these machines have the pci resources allocated like that by the BIOS, so I suspect that it's all ok. This regression goes back to commit eaba1b8f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 4 12:28:35 2013 +0100 drm/i915: Verify that our stolen memory doesn't conflict Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031Tested-by:
lu hua <huax.lu@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Eric W. Biederman authored
commit f0d62aec upstream. Generalize id_map_mutex so it can be used for more state of a user namespace. Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
commit f95d7918 upstream. If you did not create the user namespace and are allowed to write to uid_map or gid_map you should already have the necessary privilege in the parent user namespace to establish any mapping you want so this will not affect userspace in practice. Limiting unprivileged uid mapping establishment to the creator of the user namespace makes it easier to verify all credentials obtained with the uid mapping can be obtained without the uid mapping without privilege. Limiting unprivileged gid mapping establishment (which is temporarily absent) to the creator of the user namespace also ensures that the combination of uid and gid can already be obtained without privilege. This is part of the fix for CVE-2014-8989. Reviewed-by:
-
Eric W. Biederman authored
commit 80dd00a2 upstream. setresuid allows the euid to be set to any of uid, euid, suid, and fsuid. Therefor it is safe to allow an unprivileged user to map their euid and use CAP_SETUID privileged with exactly that uid, as no new credentials can be obtained. I can not find a combination of existing system calls that allows setting uid, euid, suid, and fsuid from the fsuid making the previous use of fsuid for allowing unprivileged mappings a bug. This is part of a fix for CVE-2014-8989. Reviewed-by:
-
Eric W. Biederman authored
commit be7c6dba upstream. As any gid mapping will allow and must allow for backwards compatibility dropping groups don't allow any gid mappings to be established without CAP_SETGID in the parent user namespace. For a small class of applications this change breaks userspace and removes useful functionality. This small class of applications includes tools/testing/selftests/mount/unprivilged-remount-test.c Most of the removed functionality will be added back with the addition of a one way knob to disable setgroups. Once setgroups is disabled setting the gid_map becomes as safe as setting the uid_map. For more common applications that set the uid_map and the gid_map with privilege this change will have no affect. This is part of a fix for CVE-2014-8989. Reviewed-by:
-
Eric W. Biederman authored
commit 273d2c67 upstream. setgroups is unique in not needing a valid mapping before it can be called, in the case of setgroups(0, NULL) which drops all supplemental groups. The design of the user namespace assumes that CAP_SETGID can not actually be used until a gid mapping is established. Therefore add a helper function to see if the user namespace gid mapping has been established and call that function in the setgroups permission check. This is part of the fix for CVE-2014-8989, being able to drop groups without privilege using user namespaces. Reviewed-by:
-
Benjamin Coddington authored
commit bf7491f1 upstream. Fix a bug where nfsd4_encode_components_esc() incorrectly calculates the length of server array in fs_location4--note that it is a count of the number of array elements, not a length in bytes. Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Fixes: 082d4bd7 (nfsd4: "backfill" using write_bytes_to_xdr_buf) Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Benjamin Coddington authored
commit 5a64e569 upstream. Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as an additional string encoding. Signed-off-by:
-
Rasmus Villemoes authored
commit ef17af2a upstream. Bugs similar to the one in acbbe6fb (kcmp: fix standard comparison bug) are in rich supply. In this variant, the problem is that struct xdr_netobj::len has type unsigned int, so the expression o1->len - o2->len _also_ has type unsigned int; it has completely well-defined semantics, and the result is some non-negative integer, which is always representable in a long long. But this means that if the conditional triggers, we are guaranteed to return a positive value from compare_blob. In this case it could be fixed by - res = o1->len - o2->len; + res = (long long)o1->len - (long long)o2->len; but I'd rather eliminate the usually broken 'return a - b;' idiom. Reviewed-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Bart Van Assche authored
commit c38d185d upstream. What we need is the following two guarantees: * Any thread that observes the effect of the test_and_set_bit() by __bt_get_word() also observes the preceding addition of 'current' to the appropriate wait list. This is guaranteed by the semantics of the spin_unlock() operation performed by prepare_and_wait(). Hence the conversion of test_and_set_bit_lock() into test_and_set_bit(). * The wait lists are examined by bt_clear() after the tag bit has been cleared. clear_bit_unlock() guarantees that any thread that observes that the bit has been cleared also observes the store operations preceding clear_bit_unlock(). However, clear_bit_unlock() does not prevent that the wait lists are examined before that the tag bit is cleared. Hence the addition of a memory barrier between clear_bit() and the wait list examination. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Robert Elliott <elliott@hp.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Alexander Gordeev <agordeev@redhat.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Bart Van Assche authored
commit 9e98e9d7 upstream. If __bt_get_word() is called with last_tag != 0, if the first find_next_zero_bit() fails, if after wrap-around the test_and_set_bit() call fails and find_next_zero_bit() succeeds, if the next test_and_set_bit() call fails and subsequently find_next_zero_bit() does not find a zero bit, then another wrap-around will occur. Avoid this by introducing an additional local variable. Signed-off-by:
-
Bart Van Assche authored
commit 45a9c9d9 upstream. blk-mq users are allowed to free the memory request_queue.tag_set points at after blk_cleanup_queue() has finished but before blk_release_queue() has started. This can happen e.g. in the SCSI core. The SCSI core namely embeds the tag_set structure in a SCSI host structure. The SCSI host structure is freed by scsi_host_dev_release(). This function is called after blk_cleanup_queue() finished but can be called before blk_release_queue(). This means that it is not safe to access request_queue.tag_set from inside blk_release_queue(). Hence remove the blk_sync_queue() call from blk_release_queue(). This call is not necessary - outstanding requests must have finished before blk_release_queue() is called. Additionally, move the blk_mq_free_queue() call from blk_release_queue() to blk_cleanup_queue() to avoid that struct request_queue.tag_set gets accessed after it has been freed. This patch avoids that the following kernel oops can be triggered when deleting a SCSI host for which scsi-mq was enabled: Call Trace: [<ffffffff8109a7c4>] lock_acquire+0xc4/0x270 [<ffffffff814ce111>] mutex_lock_nested+0x61/0x380 [<ffffffff812575f0>] blk_mq_free_queue+0x30/0x180 [<ffffffff8124d654>] blk_release_queue+0x84/0xd0 [<ffffffff8126c29b>] kobject_cleanup+0x7b/0x1a0 [<ffffffff8126c140>] kobject_put+0x30/0x70 [<ffffffff81245895>] blk_put_queue+0x15/0x20 [<ffffffff8125c409>] disk_release+0x99/0xd0 [<ffffffff8133d056>] device_release+0x36/0xb0 [<ffffffff8126c29b>] kobject_cleanup+0x7b/0x1a0 [<ffffffff8126c140>] kobject_put+0x30/0x70 [<ffffffff8125a78a>] put_disk+0x1a/0x20 [<ffffffff811d4cb5>] __blkdev_put+0x135/0x1b0 [<ffffffff811d56a0>] blkdev_put+0x50/0x160 [<ffffffff81199eb4>] kill_block_super+0x44/0x70 [<ffffffff8119a2a4>] deactivate_locked_super+0x44/0x60 [<ffffffff8119a87e>] deactivate_super+0x4e/0x70 [<ffffffff811b9833>] cleanup_mnt+0x43/0x90 [<ffffffff811b98d2>] __cleanup_mnt+0x12/0x20 [<ffffffff8107252c>] task_work_run+0xac/0xe0 [<ffffffff81002c01>] do_notify_resume+0x61/0xa0 [<ffffffff814d2c58>] int_signal+0x12/0x17 Signed-off-by:
-
Max Filippov authored
commit ff009ab6 upstream. Replace PAGE_KERNEL with PAGE_KERNEL_EXEC to allow copy_to_user_page invalidate icache for pages mapped with kmap. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Dave Airlie authored
commit e2809c7d upstream. On MST systems the monitors don't appear when we set the fb up, but plymouth opens the drm device and holds it open while they come up, when plymouth finishes and lastclose gets called we don't do the delayed fb probe, so the monitor never appears on the console. Fix this by moving the delayed checking into the mode restore. v2: Daniel suggested that ->delayed_hotplug is set under the mode_config mutex, so we should check it under that as well, while we are in the area. Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 19a93f04 upstream. At least on two MST devices I've tested with, when they are link training downstream, they are totally unable to handle aux ch msgs, so they defer like nuts. I tried 16, it wasn't enough, 32 seems better. This fixes one Dell 4k monitor and one of the MST hubs. v1.1: fixup comment (Tom). Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Doug Anderson authored
commit 8e2596e8 upstream. In (6468276b i2c: designware: make SCL and SDA falling time configurable) new device tree properties were added for setting the falling time of SDA and SCL. The device tree bindings doc had a typo in it: it forgot the "-ns" suffix for both properies in the prose of the bindings. I assume this is a typo because: * The source code includes the "-ns" * The example in the bindings includes the "-ns". Fix the typo. Signed-off-by:
Doug Anderson <dianders@chromium.org> Fixes: 6468276b ("i2c: designware: make SCL and SDA falling time configurable") Acked-by:
Romain Baeriswyl <romain.baeriswyl@alitech.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Luis Henriques authored
commit 9d367e5e upstream. thermal_unregister_governors() and class_unregister() were being called in the wrong order. Fixes: 80a26a5c ("Thermal: build thermal governors into thermal_sys module") Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit b26bdde5 upstream. When loading encrypted-keys module, if the last check of aes_get_sizes() in init_encrypted() fails, the driver just returns an error without unregistering its key type. This results in the stale entry in the list. In addition to memory leaks, this leads to a kernel crash when registering a new key type later. This patch fixes the problem by swapping the calls of aes_get_sizes() and register_key_type(), and releasing resources properly at the error paths. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Takashi Iwai authored
commit 66139a48 upstream. In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input URBs to reactivate the MIDI stream, but this causes the error when some of URBs are still pending like: WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70() URB ef705c40 submitted while active CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1 Hardware name: FOXCONN TPS01/TPS01, BIOS 080015 03/23/2010 c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000 c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0 f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f Call Trace: [<c0205df6>] try_stack_unwind+0x156/0x170 [<c020482a>] dump_trace+0x5a/0x1b0 [<c0205e56>] show_trace_log_lvl+0x46/0x50 [<c02049d1>] show_stack_log_lvl+0x51/0xe0 [<c0205eb7>] show_stack+0x27/0x50 [<c078deaf>] dump_stack+0x45/0x65 [<c024c884>] warn_slowpath_common+0x84/0xa0 [<c024c8d3>] warn_slowpath_fmt+0x33/0x40 [<c061ac4f>] usb_submit_urb+0x5f/0x70 [<f7974104>] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib] [<f797483a>] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib] [<c02570c0>] call_timer_fn+0x30/0x130 [<c0257442>] run_timer_softirq+0x1c2/0x260 [<c0251493>] __do_softirq+0xc3/0x270 [<c0204732>] do_softirq_own_stack+0x22/0x30 [<c025186d>] irq_exit+0x8d/0xa0 [<c0795228>] smp_apic_timer_interrupt+0x38/0x50 [<c0794a3c>] apic_timer_interrupt+0x34/0x3c [<c0673d9e>] cpuidle_enter_state+0x3e/0xd0 [<c028bb8d>] cpu_idle_loop+0x29d/0x3e0 [<c028bd23>] cpu_startup_entry+0x53/0x60 [<c0bfac1e>] start_kernel+0x415/0x41a For avoiding these errors, check the pending URBs and skip resubmitting such ones. Reported-and-tested-by:
Stefan Seyfried <stefan.seyfried@googlemail.com> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Stephane Grosjean authored
commit af35d0f1 upstream. This patch sets the correct reverse sequence order to the instructions set to run, when any failure occurs during the initialization steps. It also adds the missing unregistration call of the can device if the failure appears after having been registered. Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Stephane Grosjean authored
commit dc50ddcd upstream. This patchs fixes a misplaced call to memset() that fills the request buffer with 0. The problem was with sending PCAN_USBPRO_REQ_FCT requests, the content set by the caller was thus lost. With this patch, the memory area is zeroed only when requesting info from the device. Signed-off-by:
-
Eric W. Biederman authored
commit 0542f17b upstream. The rule is simple. Don't allow anything that wouldn't be allowed without unprivileged mappings. It was previously overlooked that establishing gid mappings would allow dropping groups and potentially gaining permission to files and directories that had lesser permissions for a specific group than for all other users. This is the rule needed to fix CVE-2014-8989 and prevent any other security issues with new_idmap_permitted. The reason for this rule is that the unix permission model is old and there are programs out there somewhere that take advantage of every little corner of it. So allowing a uid or gid mapping to be established without privielge that would allow anything that would not be allowed without that mapping will result in expectations from some code somewhere being violated. Violated expectations about the behavior of the OS is a long way to say a security issue. Signed-off-by:
-
Eric W. Biederman authored
commit 7ff4d90b upstream. Today there are 3 instances of setgroups and due to an oversight their permission checking has diverged. Add a common function so that they may all share the same permission checking code. This corrects the current oversight in the current permission checks and adds a helper to avoid this in the future. A user namespace security fix will update this new helper, shortly. Signed-off-by:
-
Takashi Iwai authored
commit fedb2245 upstream. The built-in mic boost volume gets almost muted after suspend/resume on Lenovo Ideapad S210. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88121Reported-and-tested-by:
Roman Kagan <rkagan@mail.ru> Signed-off-by:
-
Sonny Rao authored
commit 0b46b8a7 upstream. This is a bug fix for using physical arch timers when the arch_timer_use_virtual boolean is false. It restores the arch_counter_get_cntpct() function after removal in 0d651e4e "clocksource: arch_timer: use virtual counters" We need this on certain ARMv7 systems which are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset between the virtual and physical counters. Each core gets a different random offset. * The device boots in "Secure SVC" mode. * Nothing has touched the reset value of CNTHCTL.PL1PCEN or CNTHCTL.PL1PCTEN (both default to 1 at reset) One example of such as system is RK3288 where it is much simpler to use the physical counter since there's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. Fixes: 0d651e4e ("clocksource: arch_timer: use virtual counters") Signed-off-by:
Sonny Rao <sonnyrao@chromium.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Nathan Lynch authored
commit 423bd69e upstream. The arm and arm64 VDSOs need CP15 access to the architected counter. If this is unavailable (which is allowed by ARM v7), indicate this by changing the clocksource name to "arch_mem_counter" before registering the clocksource. Suggested by Stephen Boyd. Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Mahesh Salgaonkar authored
commit 682e77c8 upstream. The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting in partial invalidation of TLBs which is not right. This patch fixes that by passing IS=0xc00 to invalidate whole TLB for successful recovery from TLB and ERAT errors. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
James Hogan authored
commit ac030860 upstream. The end timer is used for switching back from repeat code timings when no repeat codes have been received for a certain amount of time. When the protocol is changed, the end timer is deleted synchronously with del_timer_sync(), however this takes place while holding the main spin lock, and the timer handler also needs to acquire the spin lock. This opens the possibility of a deadlock on an SMP system if the protocol is changed just as the repeat timer is expiring. One CPU could end up in img_ir_set_decoder() holding the lock and waiting for the end timer to complete, while the other CPU is stuck in the timer handler spinning on the lock held by the first CPU. Lockdep also spots a possible lock inversion in the same code, since img_ir_set_decoder() acquires the img-ir lock before the timer lock, but the timer handler will try and acquire them the other way around: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.18.0-rc5+ #957 Not tainted --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Dylan Rajaratnam authored
commit ea0de4ec upstream. A problem was found on Polaris where if the unit it booted via the power button on the infrared remote then the next button press on the remote would return the key code used to power on the unit. The sequence is: - The polaris powered off but with the powerdown controller (PDC) block still powered. - Press power key on remote, IR block receives the key. - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL or IMG_IR_RXDVALD2 are set. - Wait any amount of time. - Press any key. - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is unchanged since the powerup key data was never read. This is worked around by always reading the IMG_IR_DATA_x in img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or IMG_IR_RXDVALD2 bit is set. Signed-off-by:
Dylan Rajaratnam <dylan.rajaratnam@imgtec.com> Signed-off-by:
-
Stefano Stabellini authored
commit 2c3fc8d2 upstream. Need to pass the pointer within the swiotlb internal buffer to the swiotlb library, that in the case of xen_unmap_single is dev_addr, not paddr. Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by:
-
Stefano Stabellini authored
commit 9490c6c6 upstream. In xen_swiotlb_sync_single we always call xen_dma_sync_single_for_cpu, even when we should call xen_dma_sync_single_for_device. Fix that. Signed-off-by:
-
Stefano Stabellini authored
commit c884227e upstream. On x86 truncation cannot occur because config XEN depends on X86_64 || (X86_32 && X86_PAE). On ARM truncation can occur without CONFIG_ARM_LPAE, when the dma operation involves foreign grants. However in that case the physical address returned by xen_bus_to_phys is actually invalid (there is no mfn to pfn tracking for foreign grants on ARM) and it is not used. Signed-off-by:
-
Stefano Stabellini authored
commit d6883e6f upstream. xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t handle as argument, not a physical address. Signed-off-by:
-
Alex Deucher authored
commit 5e5c21ca upstream. Check the that ring we are using for copies is functional rather than the GFX ring. On newer asics we use the DMA ring for bo moves. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Dominique Leuenberger authored
commit 6583659e upstream. HP ZBook 15 laptop needs a non-standard mapping (x_inverted). BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329Signed-off-by:
Dominique Leuenberger <dimstar@opensuse.org> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Thomas Hellstrom authored
commit 89669e7a upstream. The commit "vmwgfx: Rework fence event action" introduced a number of bugs that are fixed with this commit: a) A forgotten return stateemnt. b) An if statement with identical branches. Reported-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Thomas Hellstrom authored
commit e338c4c2 upstream. The function vmw_master_check() might return -ERESTARTSYS if there is a signal pending, indicating that the IOCTL should be rerun, potentially from user-space. At that point we shouldn't print out an error message since that is not an error condition. In short, avoid bloating the kernel log when a process refuses to die on SIGTERM. Signed-off-by:
-
- 12 Jan, 2015 1 commit
-
-
Chris Wilson authored
commit 2b387059 upstream. In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
