summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-10-31drm/i915/gen9: fix plane_blocks_per_line on watermarks calculationsPaulo Zanoni1-24/+15
commit cf6c525a31fac11b0775b8c06c00a508c6356d9b upstream. The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside skl_compute_plane_wm(). The skl_wm_method2() implementation is the one that matches the specification. With this patch we fix the skl_compute_plane_wm() calculation and just pass it as a parameter to skl_wm_method2(). We also take care to not modify the value of plane_bytes_per_line since we're going to rely on it having a correct value in later patches. This should affect the watermarks for Linear and Y-tiled. From my analysis, it looks like the two plane_blocks_per_line variables got out of sync on 0fda65680e92, but we can't really say that commit was a regression, it looks like just an incomplete fix. There's always the possibility that 0fda65680e92 matched our specification at that time, and then later the specification changed. v2: Try to add a "Fixes" tag (Maarten). Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-7-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 7a1a8aed67e0a60772defe3f6499eb340da48634) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/gen9: minimum scanlines for Y tile is not always 4Paulo Zanoni1-24/+32
commit ccc1057477bc99678896b51adce6b6ee4019dc37 upstream. During watermarks calculations, this value is used in 3 different places. Only one of them was not using a hardcoded 4. Move the code up so everybody can benefit from the actual value. This should only help on situations with Y tiling + 90/270 rotation + 1 or 2 bpp or NV12. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-6-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 1186fa85eb9b3cc0589990fbc39617e50e38759a) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/gen9: fix the WaWmMemoryReadLatency implementationPaulo Zanoni1-20/+22
commit 4e4d3814a9bb4d71cd3ff0701d8d7041edefd8f0 upstream. Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing implementation from the WA implementation and fix the WA implementation. v2: Add Fixes tag (Maarten). Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level") Cc: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/gen9: only add the planes actually affected by ddb changesPaulo Zanoni1-1/+36
commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c upstream. We were previously adding all the planes owned by the CRTC even when the ddb partitioning didn't change for them. As a consequence, a lot of functions were being called when we were just moving the cursor around the screen, such as skylake_update_primary_plane(). This was causing flickering on the primary plane when moving the cursor. I'm not 100% sure which operation caused the flickering, but we were writing to a lot of registers, so it could be any of these writes. With this patch, just moving the mouse won't add the primary plane to the commit since it won't trigger a change in DDB partitioning. v2: Use skl_ddb_entry_equal() (Lyude). v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch Fixes: 05a76d3d6ad1 ("drm/i915/skl: Ensure pipes with changed wms get added to the state") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888 Cc: Mike Lothian <mike@fireburn.co.uk> Reported-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 7f60e200e254cd53ad1bd74a56bdd23e813ac4b7) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/skl: Don't try to update plane watermarks if they haven't changedLyude2-1/+14
commit ccebc23b57c313229526dc76383ce82f5e0b9001 upstream. i915 sometimes needs to disable planes in the middle of an atomic commit, and then reenable them later in the same commit. Because of this, we can't make the assumption that the state of the plane actually changed. Since the state of the plane hasn't actually changed, neither have it's watermarks. And if the watermarks hasn't changed then we haven't populated skl_results with anything, which means we'll end up zeroing out a plane's watermarks in the middle of the atomic commit without restoring them later. Simple reproduction recipe: - Get a SKL laptop, launch any kind of X session - Get two extra monitors - Keep hotplugging both displays (so that the display configuration jumps from 1 active pipe to 3 active pipes and back) - Eventually underrun Changes since v1: - Fix incorrect use of "it's" Changes since v2: - Add reproduction recipe Signed-off-by: Lyude <cpaul@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 62e0fb880123 ("drm/i915/skl: Update plane watermarks atomically during plane updates") Signed-off-by: Lyude <cpaul@redhat.com> Testcase: kms_plane Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1472488288-27280-1-git-send-email-cpaul@redhat.com Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/skl: Update DDB values atomically with wms/plane attrsLyude3-168/+132
commit 27082493e9c6371b05370a619ab9d2877c5f4726 upstream. Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is skl_update_crtcs(), which handles ensuring that we order each CRTC update in our atomic commits properly so that they honor the DDB flush order. The second major change in this patch is the order in which we flush the pipes. While the previous order may have worked, it can't be used in this approach since it no longer will do the right thing. For example, using the old ddb flush order: We have pipes A, B, and C enabled, and we're disabling C. Initial ddb allocation looks like this: | A | B |xxxxxxx| Since we're performing the ddb updates after performing any CRTC disablements in intel_atomic_commit_tail(), the space to the right of pipe B is unallocated. 1. Flush pipes with new allocation contained into old space. None apply, so we skip this 2. Flush pipes having their allocation reduced, but overlapping with a previous allocation. None apply, so we also skip this 3. Flush pipes that got more space allocated. This applies to A and B, giving us the following update order: A, B This is wrong, since updating pipe A first will cause it to overlap with B and potentially burst into flames. Our new order (see the code comments for details) would update the pipes in the proper order: B, A. As well, we calculate the order for each DDB update during the check phase, and reference it later in the commit phase when we hit skl_update_crtcs(). This long overdue patch fixes the rest of the underruns on Skylake. Changes since v1: - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm() Changes since v2: - Use the method for updating CRTCs that Ville suggested - In skl_update_wm(), only copy the watermarks for the crtc that was passed to us Changes since v3: - Small comment fix in skl_ddb_allocation_overlaps() Changes since v4: - Remove the second loop in intel_update_crtcs() and use Ville's suggestion for updating the ddb allocations in the right order - Get rid of the second loop and just use the ddb state as it updates to determine what order to update everything in (thanks for the suggestion Ville) - Simplify skl_ddb_allocation_overlaps() - Split actual overlap checking into it's own helper Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration") Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation") [omitting CC for stable, since this patch will need to be changed for such backports first] Testcase: kms_cursor_legacy Testcase: plane-all-modeset-transition Signed-off-by: Lyude <cpaul@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-2-git-send-email-cpaul@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915: Move CRTC updating in atomic_commit into it's own hookLyude2-22/+54
commit 896e5bb022bce64e29ce2e1b2fc2a7476d311a15 upstream. Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for stable branches) into it's own function, and add an appropriate display function hook for it. Based off of Matt Rope's suggestions Changes since v1: - Drop pipe_config->base.active check in intel_update_crtcs() since we check that before calling the function Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [omitting CC for stable, since this patch will need to be changed for such backports first] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-1-git-send-email-cpaul@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/skl: Update plane watermarks atomically during plane updatesLyude4-18/+64
commit 62e0fb880123c98793e5c3ba8355501b0305e92e upstream. Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are "armed", which is done by writing to the PLANE_SURF (or in the case of cursor planes, the CURBASE register) register. With this in mind, up until now we've been updating watermarks on skl like this: non-modeset { - calculate (during atomic check phase) - finish_atomic_commit: - intel_pre_plane_update: - intel_update_watermarks() - {vblank happens; new watermarks + old plane values => underrun } - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - end vblank evasion } or modeset { - calculate (during atomic check phase) - finish_atomic_commit: - crtc_enable: - intel_update_watermarks() - {vblank happens; new watermarks + old plane values => underrun } - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - end vblank evasion } Now we update watermarks atomically like this: non-modeset { - calculate (during atomic check phase) - finish_atomic_commit: - intel_pre_plane_update: - intel_update_watermarks() (wm values aren't written yet) - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - write new wm values - end vblank evasion } modeset { - calculate (during atomic check phase) - finish_atomic_commit: - crtc_enable: - intel_update_watermarks() (actual wm values aren't written yet) - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - write new wm values - end vblank evasion } So this patch moves all of the watermark writes into the right place; inside of the vblank evasion where we update all of the registers for each plane. While this patch doesn't fix everything, it does allow us to update the watermark values in the way the hardware expects us to. Changes since original patch series: - Remove mutex_lock/mutex_unlock since they don't do anything and we're not touching global state - Move skl_write_cursor_wm/skl_write_plane_wm functions into intel_pm.c, make externally visible - Add skl_write_plane_wm calls to skl_update_plane - Fix conditional for for loop in skl_write_plane_wm (level < max_level should be level <= max_level) - Make diagram in commit more accurate to what's actually happening - Add Fixes: Changes since v1: - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more then just Skylake - Update description to make it clear this patch doesn't fix everything - Check if pipes were actually changed before writing watermarks Changes since v2: - Write PIPE_WM_LINETIME during vblank evasion Changes since v3: - Rebase against new SAGV patch changes Changes since v4: - Add a parameter to choose what skl_wm_values struct to use when writing new plane watermarks Changes since v5: - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until patch 6 - Write WM_LINETIME in intel_begin_crtc_commit() Changes since v6: - Remove redundant dirty_pipes check in skl_write_plane_wm (we check this in all places where we call this function, and it was supposed to have been removed earlier anyway) - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this needs to be done for gen10 as well Changes since v7: - Fix rebase fail (unused variable obj) - Make struct skl_wm_values *wm const - Fix indenting - Use INTEL_GEN() instead of dev_priv->info.gen Changes since v8: - Don't forget calls to skl_write_plane_wm() when disabling planes - Use INTEL_GEN(), not INTEL_INFO()->gen in intel_begin_crtc_commit() Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation") Signed-off-by: Lyude <cpaul@redhat.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cpaul@redhat.com Link: http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cpaul@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31HID: add quirk for Akai MIDImix.Steinar H. Gunderson2-0/+4
commit 4973ca9a01e2354b159acedec1b9b8eb8de02ab7 upstream. The Akai MIDImix (09e8:0031) is a MIDI fader controller that speaks regular MIDI and works well with Linux. However, initialization gets delayed due to reports timeout: [3643645.631124] hid-generic 0003:09E8:0031.0020: timeout initializing reports [3643645.632416] hid-generic 0003:09E8:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-0000:00:14.0-2/input0 Adding "usbhid.quirks=0x09e8:0x0031:0x20000000" on the kernel command line makes the issues go away. Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amd/powerplay: fix mclk not switching back after multi-head was disabledRex Zhu2-1/+4
commit 9716ebc38dfabe6c8e5e3c809e9f3c61dd3740f9 upstream. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/fsl-dcu: fix endian issue when using clk_register_dividerStefan Agner1-1/+5
commit 6cc4758ae91c0582f07e3c94c7de1ad0975feff5 upstream. Since using clk_register_divider to setup the pixel clock, regmap is no longer used. Regmap did take care of DCU using different endianness. Check endianness using the device-tree property "big-endian" to determine the location of DIV_RATIO. Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel clock divider") Reported-by: Meng Yi <meng.yi@nxp.com> Signed-off-by: Stefan Agner <stefan@agner.ch> Tested-by: Meng Yi <meng.yi@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/vmwgfx: Limit the user-space command buffer sizeThomas Hellstrom1-3/+3
commit 51ab70bed997f64f091a639dbe22b629725a7faf upstream. With older hardware versions, the user could specify arbitrarily large command buffer sizes, causing a vmalloc / vmap space exhaustion. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/radeon: change vblank_time's calculation method to reduce computational ↵Alex Deucher1-7/+8
error. commit 02cfb5fccb0f9f968f0e208d89d9769aa16267bc 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>
2016-10-31drm/radeon/si/dpm: fix phase shedding setupAlex Deucher2-1/+2
commit 427920292b00474d978d632bc03a8e4e50029af3 upstream. Used the wrong index to setup the phase shedding mask. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/radeon: narrow asic_init for virtualizationAlex Deucher1-2/+3
commit 884031f0aacf57dad1575f96714efc80de9b19cc upstream. Only needed on CIK+ due to the way pci reset is handled by the GPU. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu: change vblank_time's calculation method to reduce computational ↵Rex Zhu1-6/+8
error. commit dc8184aa8621ee8048652496884d9f40d4bb407f upstream. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_initNicolai Hähnle1-0/+3
commit ce199ad690bd0a6ac6bf9e4df2c87b59d76f84da 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: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu/dce11: add missing drm_mode_config_cleanup callGrazvydas Ignotas1-0/+1
commit 140c94da3c3338c0ff4cc127cf9bec87905ca83c 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: aaa36a976bbb ("drm/amdgpu: Add initial VI support") Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu/dce11: disable hpd on local panelsAlex Deucher1-10/+13
commit 3a9d993ee9809c217f4322623a9b78c8d17fdd1f 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=97471 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu/dce8: disable hpd on local panelsAlex Deucher1-9/+39
commit 324082586cc5918e3230f0b2f326656c653201eb 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=97471 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu/dce10: disable hpd on local panelsAlex Deucher1-10/+13
commit e96ec90f496603c48e0945f8bdeb4cdf3088cbba 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=97471 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/amdgpu: fix IB alignment for UVDAlex Deucher1-1/+1
commit c4795ca642b8bd76b5b6ffba41ba909543273d43 upstream. According to the hw team, it should be 16, not 8. Cc: Peter Fang <peter.fang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/backlight: setup backlight pwm alternate increment on backlight enableShawn Lee1-1/+17
commit 915b417946030e1f365c63728875cffd8db8e880 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 e29aff05f239f8dd24e9ee7816fd96726e20105a) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/i915/backlight: setup and cache pwm alternate increment valueJani Nikula2-3/+12
commit 16e1203db8ab740c912ea62761fdf27d7811b886 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/9984b20bc59aee90b83caf59ce91f3fb122c9627.1474281249.git.jani.nikula@intel.com (cherry picked from commit 32b421e79e6b546da1d469f1229403ac9142d695) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/prime: Pass the right module owner through to dma_buf_export()Chris Wilson2-8/+12
commit 56a76c0123d6cb034975901c80fce2627338ef9e 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: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31drm/vc4: Fix races when the CS reads from render targets.Eric Anholt4-8/+62
commit 7edabee06a5622190d59689a64f5e17d1c343cc3 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: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28Linux 4.8.5v4.8.5Greg Kroah-Hartman1-1/+1
2016-10-28Revert "target: Fix residual overflow handling in ↵Nicholas Bellinger1-15/+1
target_complete_cmd_with_length" commit 61f36166c245e563c7a2b624f4c78c5ce0f680d6 upstream. This reverts commit c1ccbfe0311e2380a6d2dcb0714b36904f5d586f. 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status codeDinesh Israni1-4/+12
commit 926317de33998c112c5510301868ea9aa34097e2 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: Nixon Vincent <nixon.vincent@calsoftinc.com> Cc: Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by: Dinesh Israni <ddi@datera.io> Signed-off-by: Dinesh Israni <ddi@datera.io> Cc: Dinesh Israni <ddi@datera.io> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLENicholas Bellinger3-6/+24
commit 449a137846c84829a328757cd21fd9ca65c08519 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: Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com> Cc: Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by: Dinesh Israni <ddi@datera.io> Signed-off-by: Dinesh Israni <ddi@datera.io> Cc: Dinesh Israni <ddi@datera.io> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28target: Re-add missing SCF_ACK_KREF assignment in v4.1.yNicholas Bellinger1-1/+3
commit 527268df31e57cf2b6d417198717c6d6afdb1e3e 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 febe562c20 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: Vaibhav Tandon <vst@datera.io> Cc: Vaibhav Tandon <vst@datera.io> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28target/tcm_fc: use CPU affinity for responsesHannes Reinecke1-1/+1
commit 1ba0158fa66b5b2c597a748f87be1650c9960ccc 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: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28ubifs: Fix xattr_names length in exit pathsRichard Weinberger1-0/+2
commit 843741c5778398ea67055067f4cc65ae6c80ca0e 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28jbd2: fix incorrect unlock on j_list_lockTaesoo Kim1-1/+2
commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 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: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28ext4: do not advertise encryption support when disabledEric Biggers1-0/+4
commit c4704a4fbe834eee4109ca064131d440941f6235 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: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28fscrypto: lock inode while setting encryption policyEric Biggers1-0/+4
commit 8906a8223ad4909b391c5628f7991ebceda30e52 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 <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28fscrypto: make XTS tweak initialization endian-independentEric Biggers1-7/+8
commit fb4454376df9d820d95452d71dd83da6971f9338 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: Eric Biggers <ebiggers@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28KVM: s390: reject invalid modes for runtime instrumentationChristian Borntraeger1-2/+7
commit a5efb6b6c99a3a6dc4330f51d8066f638bdea0ac 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: c6e5f166373a ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the ledUlf Hansson1-0/+2
commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 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: Ritesh Raj Sarraf <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unusedUlf Hansson1-5/+0
commit 31cf742f515c275d22843c4c756e048d2b6d716c 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: Ritesh Raj Sarraf <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28mmc: core: switch to 1V8 or 1V2 for hs400es modeShawn Lin1-0/+10
commit 1720d3545b772c49b2975eeb3b8f4d3f56dc2085 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 81ac2af65793ecf ("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: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28mmc: core: Annotate cmd_hdr as __le32Jiri Slaby2-2/+2
commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream. Commit f68381a70bb2 (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: f68381a70bb2 (mmc: block: fix packed command header endianness) Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28powerpc/mm: Prevent unlikely crash in copro_calculate_slb()Frederic Barrat1-0/+2
commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 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: 73d16a6e0e51 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28ceph: fix error handling in ceph_read_iterNikolay Borisov1-1/+2
commit 0d7718f666be181fda1ba2d08f137d87c1419347 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: KVM: Take S1 walks into account when determining S2 write faultsWill Deacon1-5/+6
commit 60e21a0ef54cd836b9eb22c7cb396989b5b11648 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: Cortex-A53 errata workaround: check for kernel addressesAndre Przywara2-12/+23
commit 87261d19046aeaeed8eb3d2793fde850ae1b5c9e upstream. Commit 7dd01aef0557 ("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: 7dd01aef0557 ("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: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: kernel: Init MDCR_EL2 even in the absence of a PMUMarc Zyngier1-1/+2
commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream. Commit f436b2ac90a0 ("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: f436b2ac90a0 ("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: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: percpu: rewrite ll/sc loops in assemblyWill Deacon1-64/+56
commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 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: f97fc810798c ("arm64: percpu: Implement this_cpu operations") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=yArd Biesheuvel1-0/+5
commit 9c0e83c371cf4696926c95f9c8c77cd6ea803426 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: f80fb3a3d508 ("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 <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28arm64: swp emulation: bound LL/SC retries before reschedulingWill Deacon1-14/+22
commit 1c5b51dfb7b4564008e0cadec5381a69e88b0d21 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: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-14 23:38:39 +0300