- 31 Oct, 2016 14 commits
-
-
Alex Deucher authored
commit 02cfb5fc upstream. Ported from Rex's amdgpu change. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Deucher authored
commit 42792029 upstream. Used the wrong index to setup the phase shedding mask. Signed-off-by:
-
Alex Deucher authored
commit 884031f0 upstream. Only needed on CIK+ due to the way pci reset is handled by the GPU. Signed-off-by:
-
Rex Zhu authored
commit dc8184aa upstream. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Nicolai Hähnle authored
commit ce199ad6 upstream. Ensure that we really only report a GPU reset if one has happened since the creation of the context. Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 140c94da upstream. All other amdgpu/dce_v* files have this call, it's only mysteriously missing from dce_v11_0.c since the file was added and causes leaks. Fixes: aaa36a97 ("drm/amdgpu: Add initial VI support") Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit 3a9d993e upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
commit 32408258 upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
commit e96ec90f upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
commit c4795ca6 upstream. According to the hw team, it should be 16, not 8. Cc: Peter Fang <peter.fang@amd.com> Signed-off-by:
-
Shawn Lee authored
commit 915b4179 upstream. Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com (cherry picked from commit e29aff05) Signed-off-by:
-
Jani Nikula authored
commit 16e1203d upstream. This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by:
-
Chris Wilson authored
commit 56a76c01 upstream. dma_buf_export() adds a reference to the owning module to the dmabuf (to prevent the driver from being unloaded whilst a third party still refers to the dmabuf). However, drm_gem_prime_export() was passing its own THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right owner from the device->fops instead. v2: Use C99 initializers to zero out unset elements of dma_buf_export_info v3: Extract the right module from dev->fops. Testcase: igt/vgem_basic/unload Reported-by:
Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Christian König <christian.koenig@amd.com> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.ukSigned-off-by:
-
Eric Anholt authored
commit 7edabee0 upstream. With the introduction of bin/render pipelining, the previous job may not be completed when we start binning the next one. If the previous job wrote our VBO, IB, or CS textures, then the binning stage might get stale or uninitialized results. Fixes the major rendering failure in glmark2 -b terrain. Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: ca26d28b ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Signed-off-by:
-
- 28 Oct, 2016 26 commits
-
-
Greg Kroah-Hartman authored
-
Nicholas Bellinger authored
commit 61f36166 upstream. This reverts commit c1ccbfe0. Reverting this patch, as it incorrectly assumes the additional length for INQUIRY in target_complete_cmd_with_length() is SCSI allocation length, which breaks existing user-space code when SCSI allocation length is smaller than additional length. root@scsi-mq:~# sg_inq --len=4 -vvvv /dev/sdb found bsg_major=253 open /dev/sdb with flags=0x800 inquiry cdb: 12 00 00 00 04 00 duration=0 ms inquiry: pass-through requested 4 bytes (data-in) but got -28 bytes inquiry: pass-through can't get negative bytes, say it got none inquiry: got too few bytes (0) INQUIRY resid (32) should never exceed requested len=4 inquiry: failed requesting 4 byte response: Malformed response to SCSI command [resid=32] AFAICT the original change was not to address a specific host issue, so go ahead and revert to original logic for now. Cc: Douglas Gilbert <dgilbert@interlog.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Sumit Rai <sumitrai96@gmail.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Dinesh Israni authored
commit 926317de upstream. This patch addresses a bug where a local EXTENDED_COPY WRITE or READ backend I/O request would always return SAM_STAT_CHECK_CONDITION, even if underlying xcopy_pt_cmd->se_cmd generated a different SCSI status code. ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy. Reported-by:
Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by:
Dinesh Israni <ddi@datera.io> Signed-off-by:
-
Nicholas Bellinger authored
commit 449a1378 upstream. This patch addresses a bug where EXTENDED_COPY across multiple LUNs results in a CHECK_CONDITION when the source + destination are not located on the same physical node. ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE NOT REACHABLE to be returned when this occurs, in order to signal fallback to local copy method. As described in section 6.3.3 of spc4r22: "If it is not possible to complete processing of a segment because the copy manager is unable to establish communications with a copy target device, because the copy target device does not respond to INQUIRY, or because the data returned in response to INQUIRY indicates an unsupported logical unit, then the EXTENDED COPY command shall be terminated with CHECK CONDITION status, with the sense key set to COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE NOT REACHABLE." Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes. Reported-by:
-
Nicholas Bellinger authored
commit 527268df upstream. This patch fixes a regression in >= v4.1.y code where the original SCF_ACK_KREF assignment in target_get_sess_cmd() was dropped upstream in commit 054922bb, but the series for addressing TMR ABORT_TASK + LUN_RESET with fabric session reinstatement in commit febe562c still depends on this code in transport_cmd_finish_abort(). The regression manifests itself as a se_cmd->cmd_kref +1 leak, where ABORT_TASK + LUN_RESET can hang indefinately for a specific I_T session for drivers using SCF_ACK_KREF, resulting in hung kthreads. This patch has been verified with v4.1.y code. Reported-by:
Vaibhav Tandon <vst@datera.io> Tested-by:
-
Hannes Reinecke authored
commit 1ba0158f upstream. The libfc stack assigns exchange IDs based on the CPU the request was received on, so we need to send the responses via the same CPU. Otherwise the send logic gets confuses and responses will be delayed, causing exchange timeouts on the initiator side. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Richard Weinberger authored
commit 843741c5 upstream. When the operation fails we also have to undo the changes we made to ->xattr_names. Otherwise listxattr() will report wrong lengths. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Taesoo Kim authored
commit 559cce69 upstream. When 'jh->b_transaction == transaction' (asserted by below) J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... 'journal->j_list_lock' will be incorrectly unlocked, since the the lock is aquired only at the end of if / else-if statements (missing the else case). Signed-off-by:
Taesoo Kim <tsgatesv@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Fixes: 6e4862a5Signed-off-by:
-
Eric Biggers authored
commit c4704a4f upstream. The sysfs file /sys/fs/ext4/features/encryption was present on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=n. This was misleading because such kernels do not actually support ext4 encryption. Therefore, only provide this file on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=y. Note: since the ext4 feature files are all hardcoded to have a contents of "supported", it really is the presence or absence of the file that is significant, not the contents (and this change reflects that). Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
commit 8906a822 upstream. i_rwsem needs to be acquired while setting an encryption policy so that concurrent calls to FS_IOC_SET_ENCRYPTION_POLICY are correctly serialized (especially the ->get_context() + ->set_context() pair), and so that new files cannot be created in the directory during or after the ->empty_dir() check. Signed-off-by:
-
Eric Biggers authored
commit fb445437 upstream. The XTS tweak (or IV) was initialized differently on little endian and big endian systems. Because the ciphertext depends on the XTS tweak, it was not possible to use an encrypted filesystem created by a little endian system on a big endian system and vice versa, even if they shared the same PAGE_SIZE. Fix this by always using little endian. This will break hypothetical big endian users of ext4 or f2fs encryption. However, all users we are aware of are little endian, and it's believed that "real" big endian users are unlikely to exist yet. So this might as well be fixed now before it's too late. Signed-off-by:
-
Christian Borntraeger authored
commit a5efb6b6 upstream. Usually a validity intercept is a programming error of the host because of invalid entries in the state description. We can get a validity intercept if the mode of the runtime instrumentation control block is wrong. As the host does not know which modes are valid, this can be used by userspace to trigger a WARN. Instead of printing a WARN let's return an error to userspace as this can only happen if userspace provides a malformed initial value (e.g. on migration). The kernel should never warn on bogus input. Instead let's log it into the s390 debug feature. While at it, let's return -EINVAL for all validity intercepts as this will trigger an error in QEMU like error: kvm run failed Invalid argument PSW=mask 0404c00180000000 addr 000000000063c226 cc 00 R00=000000000000004f R01=0000000000000004 R02=0000000000760005 R03=000000007fe0a000 R04=000000000064ba2a R05=000000049db73dd0 R06=000000000082c4b0 R07=0000000000000041 R08=0000000000000002 R09=000003e0804042a8 R10=0000000496152c42 R11=000000007fe0afb0 [...] This will avoid an endless loop of validity intercepts. Fixes: c6e5f166 ("KVM: s390: implement the RI support of guest") Acked-by:
Fan Zhang <zhangfan@linux.vnet.ibm.com> Reviewed-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Ulf Hansson authored
commit 4f48aa7a upstream. Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device, must be done when it's runtime resumed. Currently this isn't case when changing the led, so let's fix this by adding a pm_runtime_get_sync() and a pm_runtime_put() around those operations. Reported-by:
Ritesh Raj Sarraf <rrs@researchut.com> Tested-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ulf Hansson authored
commit 31cf742f upstream. The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no SD card is inserted. This is wrong, as it could cause the device to remain runtime resumed when it's unused. Fix this behaviour. Tested-by:
-
Shawn Lin authored
commit 1720d354 upstream. When introducing hs400es, I didn't notice that we haven't switched voltage to 1V2 or 1V8 for it. That happens to work as the first controller claiming to support hs400es, arasan(5.1), which is designed to only support 1V8. So the voltage is fixed to 1V8. But it actually is wrong, and will not fit for other host controllers. Let's fix it. Fixes: commit 81ac2af6 ("mmc: core: implement enhanced strobe support") Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Jiri Slaby authored
commit 3f2d2664 upstream. Commit f68381a7 (mmc: block: fix packed command header endianness) correctly fixed endianness handling of packed_cmd_hdr in mmc_blk_packed_hdr_wrq_prep. But now, sparse complains about incorrect types: drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types) drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] <noident> drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] <noident> ... So annotate cmd_hdr properly using __le32 to make everyone happy. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Fixes: f68381a7 (mmc: block: fix packed command header endianness) Signed-off-by:
-
Frederic Barrat authored
commit d2cf909c upstream. If a cxl adapter faults on an invalid address for a kernel context, we may enter copro_calculate_slb() with a NULL mm pointer (kernel context) and an effective address which looks like a user address. Which will cause a crash when dereferencing mm. It is clearly an AFU bug, but there's no reason to crash either. So return an error, so that cxl can ack the interrupt with an address error. Fixes: 73d16a6e ("powerpc/cell: Move data segment faulting code out of cell platform") Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nikolay Borisov authored
commit 0d7718f6 upstream. In case __ceph_do_getattr returns an error and the retry_op in ceph_read_iter is not READ_INLINE, then it's possible to invoke __free_page on a page which is NULL, this naturally leads to a crash. This can happen when, for example, a process waiting on a MDS reply receives sigterm. Fix this by explicitly checking whether the page is set or not. Signed-off-by:
Nikolay Borisov <kernel@kyup.com> Reviewed-by:
Yan, Zheng <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Will Deacon authored
commit 60e21a0e upstream. The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was generated by a read or a write instruction. For stage 2 data aborts generated by a stage 1 translation table walk (i.e. the actual page table access faults at EL2), the WnR bit therefore reports whether the instruction generating the walk was a load or a store, *not* whether the page table walker was reading or writing the entry. For page tables marked as read-only at stage 2 (e.g. due to KSM merging them with the tables from another guest), this could result in livelock, where a page table walk generated by a load instruction attempts to set the access flag in the stage 1 descriptor, but fails to trigger CoW in the host since only a read fault is reported. This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to take into account stage 2 faults in stage 1 walks. Since DBM cannot be disabled at EL2 for CPUs that implement it, we assume that these faults are always causes by writes, avoiding the livelock situation at the expense of occasional, spurious CoWs. We could, in theory, do a bit better by checking the guest TCR configuration and inspecting the page table to see why the PTE faulted. However, I doubt this is measurable in practice, and the threat of livelock is real. Cc: Julien Grall <julien.grall@arm.com> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Andre Przywara authored
commit 87261d19 upstream. Commit 7dd01aef ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") adds code to execute cache maintenance instructions in the kernel on behalf of userland on CPUs with certain ARM CPU errata. It turns out that the address hasn't been checked to be a valid user space address, allowing userland to clean cache lines in kernel space. Fix this by introducing an address check before executing the instructions on behalf of userland. Since the address doesn't come via a syscall parameter, we can't just reject tagged pointers and instead have to remove the tag when checking against the user address limit. Fixes: 7dd01aef ("arm64: trap userspace "dc cvau" cache operation on errata-affected core") Reported-by:
Kristina Martsenko <kristina.martsenko@arm.com> Signed-off-by:
Andre Przywara <andre.przywara@arm.com> [will: rework commit message + replace access_ok with max_user_addr()] Signed-off-by:
-
Marc Zyngier authored
commit 85054035 upstream. Commit f436b2ac ("arm64: kernel: fix architected PMU registers unconditional access") made sure we wouldn't access unimplemented PMU registers, but also left MDCR_EL2 uninitialized in that case, leading to trap bits being potentially left set. Make sure we always write something in that register. Fixes: f436b2ac ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
commit 1e6e57d9 upstream. Writing the outer loop of an LL/SC sequence using do {...} while constructs potentially allows the compiler to hoist memory accesses between the STXR and the branch back to the LDXR. On CPUs that do not guarantee forward progress of LL/SC loops when faced with memory accesses to the same ERG (up to 2k) between the failed STXR and the branch back, we may end up livelocking. This patch avoids this issue in our percpu atomics by rewriting the outer loop as part of the LL/SC inline assembly block. Fixes: f97fc810 ("arm64: percpu: Implement this_cpu operations") Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
-
Ard Biesheuvel authored
commit 9c0e83c3 upstream. As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the kcrctab has an absolute address field that is relocated at runtime when the kernel offset is randomized. This has been fixed already for PowerPC in the past, so simply wire up the existing code dealing with this issue. Fixes: f80fb3a3 ("arm64: add support for kernel ASLR") Tested-by:
Timur Tabi <timur@codeaurora.org> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Will Deacon authored
commit 1c5b51df upstream. If a CPU does not implement a global monitor for certain memory types, then userspace can attempt a kernel DoS by issuing SWP instructions targetting the problematic memory (for example, a framebuffer mapped with non-cacheable attributes). The SWP emulation code protects against these sorts of attacks by checking for pending signals and potentially rescheduling when the STXR instruction fails during the emulation. Whilst this is good for avoiding livelock, it harms emulation of legitimate SWP instructions on CPUs where forward progress is not guaranteed if there are memory accesses to the same reservation granule (up to 2k) between the failing STXR and the retry of the LDXR. This patch solves the problem by retrying the STXR a bounded number of times (4) before breaking out of the LL/SC loop and looking for something else to do. Fixes: bd35a4ad ("arm64: Port SWP/SWPB emulation support from arm") Reviewed-by:
-
Ulf Hansson authored
commit 9158cb29 upstream. Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. This is currently not the case and it could trigger various errors. Fix this by properly deal with runtime PM in this regards. This means making sure the device is runtime resumed, when serving requests via the ->request() callback or changing settings via the ->set_param() callbacks. Cc: Ritesh Raj Sarraf <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 796aa46a upstream. Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. Therefore when the rtsx_usb_ms driver polls for inserted memstick cards, let's add pm_runtime_get|put*() to make sure accesses is done when the rtsx usb device is runtime resumed. Reported-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
