commit 957a16c3e6e19777865c2d629408d8b4396d6a4b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat Dec 21 11:05:23 2019 +0100
Linux 5.4.6
commit 2a10bf7c4704e44ee99ae6a2cefde916bbca2540
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Dec 14 18:52:17 2019 +0100
ALSA: hda: Fix regression by strip mask fix
commit 6fd739c04ffd877641b01371f9fde67901e7f9cb upstream.
The commit e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only
when needed") tried to address the regression by the unconditional
application of the stripe mask, but this caused yet another
regression for the previously working devices. Namely, the patch
clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this
may be called multiple times before restarting the stream, so this
ended up with clearance of the flag for the whole time.
This patch fixes the regression by moving the azx_dev->stripe flag
clearance at the counter-part, the close callback of HDMI codec
driver instead.
Fixes: e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only when needed")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205855
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191214175217.31852-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Stefani Seibold <stefani@seibold.net>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9375fa3799293da82490f0f1fa1f1e7fabae2745
Author: changzhu <Changfeng.Zhu@amd.com>
Date: Tue Dec 10 22:00:59 2019 +0800
drm/amdgpu: add invalidate semaphore limit for SRIOV and picasso in gmc9
commit 90f6452ca58d436de4f69b423ecd75a109aa9766 upstream.
It may fail to load guest driver in round 2 or cause Xstart problem
when using invalidate semaphore for SRIOV or picasso. So it needs avoid
using invalidate semaphore for SRIOV and picasso.
Signed-off-by: changzhu <Changfeng.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf8ae461a23577a9884f993b31b31f15dd7d6c0a
Author: changzhu <Changfeng.Zhu@amd.com>
Date: Tue Dec 10 10:23:09 2019 +0800
drm/amdgpu: avoid using invalidate semaphore for picasso
commit 413fc385a594ea6eb08843be33939057ddfdae76 upstream.
It may cause timeout waiting for sem acquire in VM flush when using
invalidate semaphore for picasso. So it needs to avoid using invalidate
semaphore for piasso.
Signed-off-by: changzhu <Changfeng.Zhu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f745d9713eceae28880893bc41c9d9e9b51a3719
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Thu Nov 21 13:57:45 2019 +0800
drm/i915/gvt: Fix cmd length check for MI_ATOMIC
commit 92b1aa773fadb4e2a90ed5d3beecb422d568ad9a upstream.
Correct valid command length check for MI_ATOMIC, need to check inline
data available field instead of operand data length for whole command.
Fixes: 00a33be40634 ("drm/i915/gvt: Add valid length check for MI variable commands")
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Gao Fred <fred.gao@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f45858245286fa901e8abf36776df7e99d9a9581
Author: Xiaojie Yuan <xiaojie.yuan@amd.com>
Date: Wed Nov 20 14:02:22 2019 +0800
drm/amdgpu/gfx10: re-init clear state buffer after gpu reset
commit 210b3b3c7563df391bd81d49c51af303b928de4a upstream.
This patch fixes 2nd baco reset failure with gfxoff enabled on navi1x.
clear state buffer (resides in vram) is corrupted after 1st baco reset,
upon gfxoff exit, CPF gets garbage header in CSIB and hangs.
Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eebab68448a6bbb9b899216b6e889057f6f4498d
Author: Xiaojie Yuan <xiaojie.yuan@amd.com>
Date: Thu Nov 14 16:56:08 2019 +0800
drm/amdgpu/gfx10: explicitly wait for cp idle after halt/unhalt
commit 1e902a6d32d73e4a6b3bc9d7cd43d4ee2b242dea upstream.
50us is not enough to wait for cp ready after gpu reset on some navi asics.
Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Suggested-by: Jack Xiao <Jack.Xiao@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69e0a0d5bcc4dd677ea460b172a1bec4127c650d
Author: changzhu <Changfeng.Zhu@amd.com>
Date: Tue Nov 19 11:13:29 2019 +0800
drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10
commit f920d1bb9c4e77efb08c41d70b6d442f46fd8902 upstream.
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in gmc9/gmc10 invalidation, add semaphore acquire
before invalidation and semaphore release after invalidation.
After adding semaphore acquire before invalidation, the semaphore
register become read-only if another process try to acquire semaphore.
Then it will not be able to release this semaphore. Then it may cause
deadlock problem. If this deadlock problem happens, it needs a semaphore
firmware fix.
Signed-off-by: changzhu <Changfeng.Zhu@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b23e536fc4d58308e3e1ae0569327995995ee378
Author: changzhu <Changfeng.Zhu@amd.com>
Date: Tue Nov 19 10:18:39 2019 +0800
drm/amdgpu: initialize vm_inv_eng0_sem for gfxhub and mmhub
commit 6c2c8972374ac5c35078d36d7559f64c368f7b33 upstream.
SW must acquire/release one of the vm_invalidate_eng*_sem around the
invalidation req/ack. Through this way,it can avoid losing invalidate
acknowledge state across power-gating off cycle.
To use vm_invalidate_eng*_sem, it needs to initialize
vm_invalidate_eng*_sem firstly.
Signed-off-by: changzhu <Changfeng.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 561595df6aa1fa9b4605d04d66798818d1658d0b
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Nov 19 15:54:17 2019 -0500
drm/amd/display: add default clocks if not able to fetch them
commit 946621691f9919c263b4679b77f81f06019d3636 upstream.
dm_pp_get_clock_levels_by_type needs to add the default clocks
to the powerplay case as well. This was accidently dropped.
Fixes: b3ea88fef321de ("drm/amd/powerplay: add get_clock_by_type interface for display")
Bug: https://gitlab.freedesktop.org/drm/amd/issues/906
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0d3e9622ad23c608d1328d88284b01f98b92a40a
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Nov 15 10:02:44 2019 -0500
drm/amd/display: re-enable wait in pipelock, but add timeout
commit 627f75d18910b287472593a4a2c41de9a386f5a2 upstream.
Removing this causes hangs in some games, so re-add it, but add
a timeout so we don't hang while switching flip types.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=112266
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 803eb244395b5901a0b56ad2081a5803b77627fc
Author: Wayne Lin <Wayne.Lin@amd.com>
Date: Tue Dec 3 12:24:23 2019 +0800
drm/dp_mst: Correct the bug in drm_dp_update_payload_part1()
commit e5a6ca27eb72c67533ddfc11c06df84beaa167fa upstream.
[Why]
If the payload_state is DP_PAYLOAD_DELETE_LOCAL in series, current
code doesn't delete the payload at current index and just move the
index to next one after shuffling payloads.
[How]
Drop the i++ increasing part in for loop head and decide whether
to increase the index or not according to payload_state of current
payload.
Changes since v1:
* Refine the code to have it easy reading
* Amend the commit message to meet the way code is modified now.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Fixes: 706246c761dd ("drm/dp_mst: Refactor drm_dp_update_payload_part1()")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Juston Li <juston.li@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.1+
[Added cc for stable]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203042423.5961-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dad25edfd31bdd7bfed9e2e7db4fc4c13058c922
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Nov 26 09:41:46 2019 -0500
drm/radeon: fix r1xx/r2xx register checker for POT textures
commit 008037d4d972c9c47b273e40e52ae34f9d9e33e7 upstream.
Shift and mask were reversed. Noticed by chance.
Tested-by: Meelis Roos <mroos@linux.ee>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 818f1c7d82cdf42d40a1e5d3f7d8de711aafeb32
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Nov 27 22:12:09 2019 +0200
drm/i915/fbc: Disable fbc by default on all glk+
commit 0eb8e74f7202a4a98bbc0c1adeed3986cf50b66a upstream.
We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit cd8c021b36a66833cefe2c90a79a9e312a2a5690)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3bf55badc225cea2d9b05da45faebc7fdd11f695
Author: Lyude Paul <lyude@redhat.com>
Date: Fri Nov 15 16:07:20 2019 -0500
drm/nouveau/kms/nv50-: Limit MST BPC to 8
commit ae5769d4670982bc483885b120b557a9ffd57527 upstream.
Noticed this while working on some unrelated CRC stuff. Currently,
userspace has very little support for BPCs higher than 8. While this
doesn't matter for most things, on MST topologies we need to be careful
about ensuring that we do our best to make any given display
configuration fit within the bandwidth restraints of the topology, since
otherwise less people's monitor configurations will work.
Allowing for BPC settings higher than 8 dramatically increases the
required bandwidth for displays in most configurations, and consequently
makes it a lot less likely that said display configurations will pass
the atomic check.
In the future we want to fix this correctly by making it so that we
adjust the bpp for each display in a topology to be as high as possible,
while making sure to lower the bpp of each display in the event that we
run out of bandwidth and need to rerun our atomic check. But for now,
follow the behavior that both i915 and amdgpu are sticking to.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@redhat.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: <stable@vger.kernel.org> # v5.1+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 54c9347feaf8fe34f5846f43757a341d80382cc2
Author: Lyude Paul <lyude@redhat.com>
Date: Fri Nov 15 16:07:19 2019 -0500
drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom
commit ac2d9275f371346922b31a388bbaa6a54f1154a4 upstream.
In order to be able to use bpc values that are different from what the
connector reports, we want to be able to store the bpc value we decide
on using for an atomic state in nv50_head_atom and refer to that instead
of simply using the value that the connector reports throughout the
whole atomic check phase and commit phase. This will let us (eventually)
implement the max bpc connector property, and will also be needed for
limiting the bpc we use on MST displays to 8 in the next commit.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@redhat.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <stable@vger.kernel.org> # v5.1+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d94c3f3c47c8a225e7ff7c657d4831124a0f3f9
Author: Lyude Paul <lyude@redhat.com>
Date: Fri Nov 15 16:07:18 2019 -0500
drm/nouveau/kms/nv50-: Call outp_atomic_check_view() before handling PBN
commit 310d35771ee9040f5744109fc277206ad96ba253 upstream.
Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
probably should be calling it before handling any PBN changes. Just a
precaution.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@redhat.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <stable@vger.kernel.org> # v5.1+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2dfbb6448c16874e54845bb4bbe878fad250d0b6
Author: Michael Hernandez <mhernandez@marvell.com>
Date: Tue Dec 3 14:36:57 2019 -0800
scsi: qla2xxx: Fix incorrect SFUB length used for Secure Flash Update MB Cmd
commit c868907e1ac6a08a17f8fa9ce482c0a496896e9e upstream.
SFUB length should be in DWORDs when passed to FW.
Fixes: 3f006ac342c03 ("scsi: qla2xxx: Secure flash update support for ISP28XX")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191203223657.22109-4-hmadhani@marvell.com
Signed-off-by: Michael Hernandez <mhernandez@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69b0e7e76adaa8bc7b7ad28a1a055d6e355d017a
Author: Himanshu Madhani <hmadhani@marvell.com>
Date: Tue Dec 3 14:36:55 2019 -0800
scsi: qla2xxx: Correctly retrieve and interpret active flash region
commit 4e71dcae0c4cd1e9d19b8b3d80214a4bcdca5a42 upstream.
ISP27XX/28XX supports multiple flash regions. This patch fixes issue where
active flash region was not interpreted correctly during secure flash
update process.
[mkp: typo]
Fixes: 5fa8774c7f38c ("scsi: qla2xxx: Add 28xx flash primary/secondary status/image mechanism")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191203223657.22109-2-hmadhani@marvell.com
Signed-off-by: Michael Hernandez <mhernandez@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a82545b62e07200c20481e76b6adb7856a24013a
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date: Mon Nov 25 19:56:54 2019 +0300
scsi: qla2xxx: Change discovery state before PLOGI
commit 58e39a2ce4be08162c0368030cdc405f7fd849aa upstream.
When a port sends PLOGI, discovery state should be changed to login
pending, otherwise RELOGIN_NEEDED bit is set in
qla24xx_handle_plogi_done_event(). RELOGIN_NEEDED triggers another PLOGI,
and it never goes out of the loop until login timer expires.
Fixes: 8777e4314d397 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")
Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag")
Cc: Quinn Tran <qutran@marvell.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191125165702.1013-6-r.bolshakov@yadro.com
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f9daaba80483fa1f5740c9fef89e95a9879c38a4
Author: Michael Hernandez <mhernandez@marvell.com>
Date: Tue Dec 3 14:36:56 2019 -0800
scsi: qla2xxx: Added support for MPI and PEP regions for ISP28XX
commit a530bf691f0e4691214562c165e6c8889dc51e57 upstream.
This patch adds support for MPI/PEP region updates which is required with
secure flash updates for ISP28XX.
Fixes: 3f006ac342c0 ("scsi: qla2xxx: Secure flash update support for ISP28XX")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191203223657.22109-3-hmadhani@marvell.com
Signed-off-by: Michael Hernandez <mhernandez@marvell.com>
Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 09f401b656a01a5cbc0db9ce5fb261f976011622
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date: Mon Nov 25 19:56:52 2019 +0300
scsi: qla2xxx: Initialize free_work before flushing it
commit 4c86b037a6db3ad2922ef3ba8a8989eb7794e040 upstream.
Target creation triggers a new BUG_ON introduced in in commit 4d43d395fed1
("workqueue: Try to catch flush_work() without INIT_WORK()."). The BUG_ON
reveals an attempt to flush free_work in qla24xx_do_nack_work before it's
initialized in qlt_unreg_sess:
WARNING: CPU: 7 PID: 211 at kernel/workqueue.c:3031 __flush_work.isra.38+0x40/0x2e0
CPU: 7 PID: 211 Comm: kworker/7:1 Kdump: loaded Tainted: G E 5.3.0-rc7-vanilla+ #2
Workqueue: qla2xxx_wq qla2x00_iocb_work_fn [qla2xxx]
NIP: c000000000159620 LR: c0080000009d91b0 CTR: c0000000001598c0
REGS: c000000005f3f730 TRAP: 0700 Tainted: G E (5.3.0-rc7-vanilla+)
MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002222 XER: 00000000
CFAR: c0000000001598d0 IRQMASK: 0
GPR00: c0080000009d91b0 c000000005f3f9c0 c000000001670a00 c0000003f8655ca8
GPR04: c0000003f8655c00 000000000000ffff 0000000000000011 ffffffffffffffff
GPR08: c008000000949228 0000000000000000 0000000000000001 c0080000009e7780
GPR12: 0000000000002200 c00000003fff6200 c000000000161bc8 0000000000000004
GPR16: c0000003f9d68280 0000000002000000 0000000000000005 0000000000000003
GPR20: 0000000000000002 000000000000ffff 0000000000000000 fffffffffffffef7
GPR24: c000000004f73848 c000000004f73838 c000000004f73f28 c000000005f3fb60
GPR28: c000000004f73e48 c000000004f73c80 c000000004f73818 c0000003f9d68280
NIP [c000000000159620] __flush_work.isra.38+0x40/0x2e0
LR [c0080000009d91b0] qla24xx_do_nack_work+0x88/0x180 [qla2xxx]
Call Trace:
[c000000005f3f9c0] [c000000000159644] __flush_work.isra.38+0x64/0x2e0 (unreliable)
[c000000005f3fa50] [c0080000009d91a0] qla24xx_do_nack_work+0x78/0x180 [qla2xxx]
[c000000005f3fae0] [c0080000009496ec] qla2x00_do_work+0x604/0xb90 [qla2xxx]
[c000000005f3fc40] [c008000000949cd8] qla2x00_iocb_work_fn+0x60/0xe0 [qla2xxx]
[c000000005f3fc80] [c000000000157bb8] process_one_work+0x2c8/0x5b0
[c000000005f3fd10] [c000000000157f28] worker_thread+0x88/0x660
[c000000005f3fdb0] [c000000000161d64] kthread+0x1a4/0x1b0
[c000000005f3fe20] [c00000000000b960] ret_from_kernel_thread+0x5c/0x7c
Instruction dump:
3d22001d 892966b1 7d908026 91810008 f821ff71 69290001 0b090000 2e290000
40920200 e9230018 7d2a0074 794ad182 <0b0a0000> 2fa90000 419e01e8 7c0802a6
---[ end trace 5ccf335d4f90fcb8 ]---
Fixes: 1021f0bc2f3d6 ("scsi: qla2xxx: allow session delete to finish before create.")
Cc: Quinn Tran <qutran@marvell.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191125165702.1013-4-r.bolshakov@yadro.com
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe6e4d041c074a706dc1e186ad2491c36ebecb30
Author: Roman Bolshakov <r.bolshakov@yadro.com>
Date: Mon Nov 25 19:56:50 2019 +0300
scsi: qla2xxx: Ignore NULL pointer in tcm_qla2xxx_free_mcmd
commit f2c9ee54a56995a293efef290657d8a1d80e14ab upstream.
If ABTS cannot be completed in target mode, the driver attempts to free
related management command and crashes:
NIP [d000000019181ee8] tcm_qla2xxx_free_mcmd+0x40/0x80 [tcm_qla2xxx]
LR [d00000001dc1e6f8] qlt_response_pkt+0x190/0xa10 [qla2xxx]
Call Trace:
[c000003fff27bb50] [c000003fff27bc10] 0xc000003fff27bc10 (unreliable)
[c000003fff27bb70] [d00000001dc1e6f8] qlt_response_pkt+0x190/0xa10 [qla2xxx]
[c000003fff27bc10] [d00000001dbc2be0] qla24xx_process_response_queue+0x5d8/0xbd0 [qla2xxx]
[c000003fff27bd50] [d00000001dbc632c] qla24xx_msix_rsp_q+0x64/0x150 [qla2xxx]
[c000003fff27bde0] [c000000000187200] __handle_irq_event_percpu+0x90/0x310
[c000003fff27bea0] [c0000000001874b8] handle_irq_event_percpu+0x38/0x90
[c000003fff27bee0] [c000000000187574] handle_irq_event+0x64/0xb0
[c000003fff27bf10] [c00000000018cd38] handle_fasteoi_irq+0xe8/0x280
[c000003fff27bf40] [c000000000185ccc] generic_handle_irq+0x4c/0x70
[c000003fff27bf60] [c000000000016cec] __do_irq+0x7c/0x1d0
[c000003fff27bf90] [c00000000002a530] call_do_irq+0x14/0x24
[c00000207d2cba90] [c000000000016edc] do_IRQ+0x9c/0x130
[c00000207d2cbae0] [c000000000008bf4] hardware_interrupt_common+0x114/0x120
--- interrupt: 501 at arch_local_irq_restore+0x74/0x90
LR = arch_local_irq_restore+0x74/0x90
[c00000207d2cbdd0] [c0000000001c64fc] tick_broadcast_oneshot_control+0x4c/0x60 (unreliable)
[c00000207d2cbdf0] [c0000000007ac840] cpuidle_enter_state+0xf0/0x450
[c00000207d2cbe50] [c00000000016b81c] call_cpuidle+0x4c/0x90
[c00000207d2cbe70] [c00000000016bc30] do_idle+0x2b0/0x330
[c00000207d2cbec0] [c00000000016beec] cpu_startup_entry+0x3c/0x50
[c00000207d2cbef0] [c00000000004a06c] start_secondary+0x63c/0x670
[c00000207d2cbf90] [c00000000000aa6c] start_secondary_prolog+0x10/0x14
The crash can be triggered by ACL deletion when there's active I/O.
During ACL deletion, qla2xxx performs implicit LOGO that's invisible for
the initiator. Only the driver and firmware are aware of the logout.
Therefore the initiator continues to send SCSI commands and the target
always responds with SAM STATUS BUSY as it can't find the session.
The command times out after a while and initiator invokes ABORT TASK TMF
for the command. The TMF is mapped to ABTS-LS in FCP. The target can't find
session for S_ID originating ABTS-LS so it never allocates mcmd. And since
N_Port handle was deleted after LOGO, it is no longer valid and ABTS
Response IOCB is returned from firmware with status 31. Then free_mcmd is
invoked on NULL pointer and the kernel crashes.
[ 7734.578642] qla2xxx [0000:00:0c.0]-e837:6: ABTS_RECV_24XX: instance 0
[ 7734.578644] qla2xxx [0000:00:0c.0]-f811:6: qla_target(0): task abort (s_id=1:2:0, tag=1209504, param=0)
[ 7734.578645] find_sess_by_s_id: 0x010200
[ 7734.578645] Unable to locate s_id: 0x010200
[ 7734.578646] qla2xxx [0000:00:0c.0]-f812:6: qla_target(0): task abort for non-existent session
[ 7734.578648] qla2xxx [0000:00:0c.0]-e806:6: Sending task mgmt ABTS response (ha=c0000000d5819000, atio=c0000000d3fd4700, status=4
[ 7734.578730] qla2xxx [0000:00:0c.0]-e838:6: ABTS_RESP_24XX: compl_status 31
[ 7734.578732] qla2xxx [0000:00:0c.0]-e863:6: qla_target(0): ABTS_RESP_24XX failed 31 (subcode 19:a)
[ 7734.578740] Unable to handle kernel paging request for data at address 0x00000200
Fixes: 6b0431d6fa20b ("scsi: qla2xxx: Fix out of order Termination and ABTS response")
Cc: Quinn Tran <qutran@marvell.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Thomas Abraham <tabraham@suse.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191125165702.1013-2-r.bolshakov@yadro.com
Acked-by: Himanshu Madhani <hmadhani@marvell.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 80dfdacecf54f140d9f0e7ed8bc1627be4b897ce
Author: Bart Van Assche <bvanassche@acm.org>
Date: Mon Dec 9 09:34:57 2019 -0800
scsi: iscsi: Fix a potential deadlock in the timeout handler
commit 5480e299b5ae57956af01d4839c9fc88a465eeab upstream.
Some time ago the block layer was modified such that timeout handlers are
called from thread context instead of interrupt context. Make it safe to
run the iSCSI timeout handler in thread context. This patch fixes the
following lockdep complaint:
================================
WARNING: inconsistent lock state
5.5.1-dbg+ #11 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/7:1H/206 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff88802d9827e8 (&(&session->frwd_lock)->rlock){+.?.}, at: iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x106/0x240
_raw_spin_lock+0x38/0x50
iscsi_check_transport_timeouts+0x3e/0x210 [libiscsi]
call_timer_fn+0x132/0x470
__run_timers.part.0+0x39f/0x5b0
run_timer_softirq+0x63/0xc0
__do_softirq+0x12d/0x5fd
irq_exit+0xb3/0x110
smp_apic_timer_interrupt+0x131/0x3d0
apic_timer_interrupt+0xf/0x20
default_idle+0x31/0x230
arch_cpu_idle+0x13/0x20
default_idle_call+0x53/0x60
do_idle+0x38a/0x3f0
cpu_startup_entry+0x24/0x30
start_secondary+0x222/0x290
secondary_startup_64+0xa4/0xb0
irq event stamp: 1383705
hardirqs last enabled at (1383705): [<ffffffff81aace5c>] _raw_spin_unlock_irq+0x2c/0x50
hardirqs last disabled at (1383704): [<ffffffff81aacb98>] _raw_spin_lock_irq+0x18/0x50
softirqs last enabled at (1383690): [<ffffffffa0e2efea>] iscsi_queuecommand+0x76a/0xa20 [libiscsi]
softirqs last disabled at (1383682): [<ffffffffa0e2e998>] iscsi_queuecommand+0x118/0xa20 [libiscsi]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&session->frwd_lock)->rlock);
<Interrupt>
lock(&(&session->frwd_lock)->rlock);
*** DEADLOCK ***
2 locks held by kworker/7:1H/206:
#0: ffff8880d57bf928 ((wq_completion)kblockd){+.+.}, at: process_one_work+0x472/0xab0
#1: ffff88802b9c7de8 ((work_completion)(&q->timeout_work)){+.+.}, at: process_one_work+0x476/0xab0
stack backtrace:
CPU: 7 PID: 206 Comm: kworker/7:1H Not tainted 5.5.1-dbg+ #11
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: kblockd blk_mq_timeout_work
Call Trace:
dump_stack+0xa5/0xe6
print_usage_bug.cold+0x232/0x23b
mark_lock+0x8dc/0xa70
__lock_acquire+0xcea/0x2af0
lock_acquire+0x106/0x240
_raw_spin_lock+0x38/0x50
iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
scsi_times_out+0xf4/0x440 [scsi_mod]
scsi_timeout+0x1d/0x20 [scsi_mod]
blk_mq_check_expired+0x365/0x3a0
bt_iter+0xd6/0xf0
blk_mq_queue_tag_busy_iter+0x3de/0x650
blk_mq_timeout_work+0x1af/0x380
process_one_work+0x56d/0xab0
worker_thread+0x7a/0x5d0
kthread+0x1bc/0x210
ret_from_fork+0x24/0x30
Fixes: 287922eb0b18 ("block: defer timeouts to a workqueue")
Cc: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Lee Duncan <lduncan@suse.com>
Cc: Chris Leech <cleech@redhat.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191209173457.187370-1-bvanassche@acm.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f306f06d9a157774eec9b6129d72c59a0f136b0a
Author: sheebab <sheebab@cadence.com>
Date: Tue Dec 3 11:07:15 2019 +0100
scsi: ufs: Disable autohibern8 feature in Cadence UFS
commit d168001d14eccfda229b4a41a2c31a21e3c379da upstream.
This patch disables autohibern8 feature in Cadence UFS. The autohibern8
feature has issues due to which unexpected interrupt trigger is happening.
After the interrupt issue is sorted out, autohibern8 feature will be
re-enabled
Link: https://lore.kernel.org/r/1575367635-22662-1-git-send-email-sheebab@cadence.com
Cc: <stable@vger.kernel.org>
Signed-off-by: sheebab <sheebab@cadence.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3e1ba0bef439a58b6cd2e052989eefc07ef165c
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date: Wed Dec 4 16:07:42 2019 +0200
dm thin: Flush data device before committing metadata
commit 694cfe7f31db36912725e63a38a5179c8628a496 upstream.
The thin provisioning target maintains per thin device mappings that map
virtual blocks to data blocks in the data device.
When we write to a shared block, in case of internal snapshots, or
provision a new block, in case of external snapshots, we copy the shared
block to a new data block (COW), update the mapping for the relevant
virtual block and then issue the write to the new data block.
Suppose the data device has a volatile write-back cache and the
following sequence of events occur:
1. We write to a shared block
2. A new data block is allocated
3. We copy the shared block to the new data block using kcopyd (COW)
4. We insert the new mapping for the virtual block in the btree for that
thin device.
5. The commit timeout expires and we commit the metadata, that now
includes the new mapping from step (4).
6. The system crashes and the data device's cache has not been flushed,
meaning that the COWed data are lost.
The next time we read that virtual block of the thin device we read it
from the data block allocated in step (2), since the metadata have been
successfully committed. The data are lost due to the crash, so we read
garbage instead of the old, shared data.
This has the following implications:
1. In case of writes to shared blocks, with size smaller than the pool's
block size (which means we first copy the whole block and then issue
the smaller write), we corrupt data that the user never touched.
2. In case of writes to shared blocks, with size equal to the device's
logical block size, we fail to provide atomic sector writes. When the
system recovers the user will read garbage from that sector instead
of the old data or the new data.
3. Even for writes to shared blocks, with size equal to the pool's block
size (overwrites), after the system recovers, the written sectors
will contain garbage instead of a random mix of sectors containing
either old data or new data, thus we fail again to provide atomic
sectors writes.
4. Even when the user flushes the thin device, because we first commit
the metadata and then pass down the flush, the same risk for
corruption exists (if the system crashes after the metadata have been
committed but before the flush is passed down to the data device.)
The only case which is unaffected is that of writes with size equal to
the pool's block size and with the FUA flag set. But, because FUA writes
trigger metadata commits, this case can trigger the corruption
indirectly.
Moreover, apart from internal and external snapshots, the same issue
exists for newly provisioned blocks, when block zeroing is enabled.
After the system recovers the provisioned blocks might contain garbage
instead of zeroes.
To solve this and avoid the potential data corruption we flush the
pool's data device **before** committing its metadata.
This ensures that the data blocks of any newly inserted mappings are
properly written to non-volatile storage and won't be lost in case of a
crash.
Cc: stable@vger.kernel.org
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d2688d36ced2d82b7a2cb24e85b511e969ebfe20
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date: Wed Dec 4 16:07:41 2019 +0200
dm thin metadata: Add support for a pre-commit callback
commit ecda7c0280e6b3398459dc589b9a41c1adb45529 upstream.
Add support for one pre-commit callback which is run right before the
metadata are committed.
This allows the thin provisioning target to run a callback before the
metadata are committed and is required by the next commit.
Cc: stable@vger.kernel.org
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a802c5c9f4e6b47b85ba27d36f8c1fd3386b19f2
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date: Wed Dec 4 16:06:54 2019 +0200
dm clone: Flush destination device before committing metadata
commit 8b3fd1f53af3591d5624ab9df718369b14d09ed1 upstream.
dm-clone maintains an on-disk bitmap which records which regions are
valid in the destination device, i.e., which regions have already been
hydrated, or have been written to directly, via user I/O.
Setting a bit in the on-disk bitmap meas the corresponding region is
valid in the destination device and we redirect all I/O regarding it to
the destination device.
Suppose the destination device has a volatile write-back cache and the
following sequence of events occur:
1. A region gets hydrated, either through the background hydration or
because it was written to directly, via user I/O.
2. The commit timeout expires and we commit the metadata, marking that
region as valid in the destination device.
3. The system crashes and the destination device's cache has not been
flushed, meaning the region's data are lost.
The next time we read that region we read it from the destination
device, since the metadata have been successfully committed, but the
data are lost due to the crash, so we read garbage instead of the old
data.
This has several implications:
1. In case of background hydration or of writes with size smaller than
the region size (which means we first copy the whole region and then
issue the smaller write), we corrupt data that the user never
touched.
2. In case of writes with size equal to the device's logical block size,
we fail to provide atomic sector writes. When the system recovers the
user will read garbage from the sector instead of the old data or the
new data.
3. In case of writes without the FUA flag set, after the system
recovers, the written sectors will contain garbage instead of a
random mix of sectors containing either old data or new data, thus we
fail again to provide atomic sector writes.
4. Even when the user flushes the dm-clone device, because we first
commit the metadata and then pass down the flush, the same risk for
corruption exists (if the system crashes after the metadata have been
committed but before the flush is passed down).
The only case which is unaffected is that of writes with size equal to
the region size and with the FUA flag set. But, because FUA writes
trigger metadata commits, this case can trigger the corruption
indirectly.
To solve this and avoid the potential data corruption we flush the
destination device **before** committing the metadata.
This ensures that any freshly hydrated regions, for which we commit the
metadata, are properly written to non-volatile storage and won't be lost
in case of a crash.
Fixes: 7431b7835f55 ("dm: add clone target")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f03887fcb13bf6620fd5231b15d32a5cce519572
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date: Wed Dec 4 16:06:53 2019 +0200
dm clone metadata: Use a two phase commit
commit 8fdbfe8d1690e8a38d497d83a30607d0d90cc15a upstream.
Split the metadata commit in two parts:
1. dm_clone_metadata_pre_commit(): Prepare the current transaction for
committing. After this is called, all subsequent metadata updates,
done through either dm_clone_set_region_hydrated() or
dm_clone_cond_set_range(), will be part of the next transaction.
2. dm_clone_metadata_commit(): Actually commit the current transaction
to disk and start a new transaction.
This is required by the following commit. It allows dm-clone to flush
the destination device after step (1) to ensure that all freshly
hydrated regions, for which we are updating the metadata, are properly
written to non-volatile storage and won't be lost in case of a crash.
Fixes: 7431b7835f55 ("dm: add clone target")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aeb8a795f6d577606293e7ddc11ab00d160bfe4b
Author: Nikos Tsironis <ntsironis@arrikto.com>
Date: Wed Dec 4 16:06:52 2019 +0200
dm clone metadata: Track exact changes per transaction
commit e6a505f3f9fae572fb3ab3bc486e755ac9cef32c upstream.
Extend struct dirty_map with a second bitmap which tracks the exact
regions that were hydrated during the current metadata transaction.
Moreover, fix __flush_dmap() to only commit the metadata of the regions
that were hydrated during the current transaction.
This is required by the following commits to fix a data corruption bug.
Fixes: 7431b7835f55 ("dm: add clone target")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f07f8a999f32746291f1b8300bf293637283919
Author: Hou Tao <houtao1@huawei.com>
Date: Tue Dec 3 19:42:58 2019 +0800
dm btree: increase rebalance threshold in __rebalance2()
commit 474e559567fa631dea8fb8407ab1b6090c903755 upstream.
We got the following warnings from thin_check during thin-pool setup:
$ thin_check /dev/vdb
examining superblock
examining devices tree
missing devices: [1, 84]
too few entries in btree_node: 41, expected at least 42 (block 138, max_entries = 126)
examining mapping tree
The phenomenon is the number of entries in one node of details_info tree is
less than (max_entries / 3). And it can be easily reproduced by the following
procedures:
$ new a thin pool
$ presume the max entries of details_info tree is 126
$ new 127 thin devices (e.g. 1~127) to make the root node being full
and then split
$ remove the first 43 (e.g. 1~43) thin devices to make the children
reblance repeatedly
$ stop the thin pool
$ thin_check
The root cause is that the B-tree removal procedure in __rebalance2()
doesn't guarantee the invariance: the minimal number of entries in
non-root node should be >= (max_entries / 3).
Simply fix the problem by increasing the rebalance threshold to
make sure the number of entries in each child will be greater
than or equal to (max_entries / 3 + 1), so no matter which
child is used for removal, the number will still be valid.
Cc: stable@vger.kernel.org
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e53ea4a1641c463d5369f800734920f1dac56c2
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Nov 26 10:08:29 2019 -0500
dm mpath: remove harmful bio-based optimization
commit dbaf971c9cdf10843071a60dcafc1aaab3162354 upstream.
Removes the branching for edge-case where no SCSI device handler
exists. The __map_bio_fast() method was far too limited, by only
selecting a new pathgroup or path IFF there was a path failure, fix this
be eliminating it in favor of __map_bio(). __map_bio()'s extra SCSI
device handler specific MPATHF_PG_INIT_REQUIRED test is not in the fast
path anyway.
This change restores full path selector functionality for bio-based
configurations that don't haave a SCSI device handler. But it should be
noted that the path selectors do have an impact on performance for
certain networks that are extremely fast (and don't require frequent
switching).
Fixes: 8d47e65948dd ("dm mpath: remove unnecessary NVMe branching in favor of scsi_dh checks")
Cc: stable@vger.kernel.org
Reported-by: Drew Hastings <dhastings@crucialwebhost.com>
Suggested-by: Martin Wilck <mwilck@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e08c605d22ab088e9e09283d98614fb59e5fe177
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Sun Dec 8 18:18:31 2019 +0100
drm: meson: venc: cvbs: fix CVBS mode matching
commit 43cb86799ff03e9819c07f37f72f80f8246ad7ed upstream.
With commit 222ec1618c3ace ("drm: Add aspect ratio parsing in DRM
layer") the drm core started honoring the picture_aspect_ratio field
when comparing two drm_display_modes. Prior to that it was ignored.
When the CVBS encoder driver was initially submitted there was no aspect
ratio check.
Switch from drm_mode_equal() to drm_mode_match() without
DRM_MODE_MATCH_ASPECT_RATIO to fix "kmscube" and X.org output using the
CVBS connector. When (for example) kmscube sets the output mode when
using the CVBS connector it passes HDMI_PICTURE_ASPECT_NONE, making the
drm_mode_equal() fail as it include the aspect ratio.
Prior to this patch kmscube reported:
failed to set mode: Invalid argument
The CVBS mode checking in the sun4i (drivers/gpu/drm/sun4i/sun4i_tv.c
sun4i_tv_mode_to_drm_mode) and ZTE (drivers/gpu/drm/zte/zx_tvenc.c
tvenc_mode_{pal,ntsc}) drivers don't set the "picture_aspect_ratio" at
all. The Meson VPU driver does not rely on the aspect ratio for the CVBS
output so we can safely decouple it from the hdmi_picture_aspect
setting.
Cc: <stable@vger.kernel.org>
Fixes: 222ec1618c3ace ("drm: Add aspect ratio parsing in DRM layer")
Fixes: bbbe775ec5b5da ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: squashed with drm: meson: venc: cvbs: deduplicate the meson_cvbs_mode lookup code]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191208171832.1064772-3-martin.blumenstingl@googlemail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21cc694b6a5ddc8b00f1a16a4a02f115548caafd
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Fri Dec 6 09:19:01 2019 +0100
drm/mgag200: Flag all G200 SE A machines as broken wrt <startadd>
commit 4adf0b49eea926a55fd956ef7d86750f771435ff upstream.
Several MGA G200 SE machines don't respect the value of the startadd
register field. After more feedback on affected machines, neither PCI
subvendor ID nor the internal ID seem to hint towards the bug. All
affected machines have a PCI ID of 0x0522 (i.e., G200 SE A). It was
decided to flag all G200 SE A machines as broken.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Fixes: 1591fadf857c ("drm/mgag200: Add workaround for HW that does not support 'startadd'")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: John Donnelly <john.p.donnelly@oracle.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Y.C. Chen" <yc_chen@aspeedtech.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.3+
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Allison Randal <allison@lohutok.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206081901.9938-1-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cd2e3c349c303dad85acbaab13a2c1b6b5a4cd52
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Nov 26 11:15:29 2019 +0100
drm/mgag200: Add workaround for HW that does not support 'startadd'
commit 1591fadf857cdbaf2baa55e421af99a61354713c upstream.
There's at least one system that does not interpret the value of
the device's 'startadd' field correctly, which leads to incorrectly
displayed scanout buffers. Always placing the active scanout buffer
at offset 0 works around the problem.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: John Donnelly <john.p.donnelly@oracle.com>
Tested-by: John Donnelly <john.p.donnelly@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Y.C. Chen" <yc_chen@aspeedtech.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.3+
Link: https://gitlab.freedesktop.org/drm/misc/issues/7
Link: https://patchwork.freedesktop.org/patch/msgid/20191126101529.20356-4-tzimmermann@suse.de
[drop debugfs_init callback - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2da836c42ff36d624039f0a1fd8500af6217b2c2
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Nov 26 11:15:28 2019 +0100
drm/mgag200: Store flags from PCI driver data in device structure
commit d6d437d97d54c85a1a93967b2745e31dff03365a upstream.
The flags field in struct mga_device has been unused so far. We now
use it to store flag bits from the PCI driver.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin")
Cc: John Donnelly <john.p.donnelly@oracle.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: "Y.C. Chen" <yc_chen@aspeedtech.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.3+
Link: https://patchwork.freedesktop.org/patch/msgid/20191126101529.20356-3-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ccc2be44edff74a0ede75ebde18150b18df207c7
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Nov 26 11:15:27 2019 +0100
drm/mgag200: Extract device type from flags
commit 3a8a5aba142a44eaeba0cb0ec1b4a8f177b5e59a upstream.
Adds a conversion function that extracts the device type from the
PCI id-table flags. Allows for storing additional information in the
other flag bits.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Donnelly <john.p.donnelly@oracle.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: "Y.C. Chen" <yc_chen@aspeedtech.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.3+
Link: https://patchwork.freedesktop.org/patch/msgid/20191126101529.20356-2-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2655948b599ca346b75b4a672a3d170aa695e8ff
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date: Fri Nov 29 14:59:04 2019 +0100
drm/panfrost: Fix a race in panfrost_gem_free_object()
commit aed44cbeae2b7674cd155ba5cc6506aafe46a94e upstream.
panfrost_gem_shrinker_scan() might purge a BO (release the sgt and
kill the GPU mapping) that's being freed by panfrost_gem_free_object()
if we don't remove the BO from the shrinker list at the beginning of
panfrost_gem_free_object().
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-5-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab84a17e78cf3c5380465f2a530c29ec96945178
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date: Fri Nov 29 14:59:03 2019 +0100
drm/panfrost: Fix a BO leak in panfrost_ioctl_mmap_bo()
commit 3bb69dbcb9e8430e0cc9990cff427ca3ae25ffdc upstream.
We should release the reference we grabbed when an error occurs.
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-4-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ecf1946856224ebde8078a94bebba95222456b3
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date: Fri Nov 29 14:59:02 2019 +0100
drm/panfrost: Fix a race in panfrost_ioctl_madvise()
commit 70cc77952efebf6722d483cb83cfb563ac9768db upstream.
If 2 threads change the MADVISE property of the same BO in parallel we
might end up with an shmem->madv value that's inconsistent with the
presence of the BO in the shrinker list.
The easiest solution to fix that is to protect the
drm_gem_shmem_madvise() call with the shrinker lock.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-3-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c902404d5013e57dbe08be0b8b36dffb08c6f46e
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Fri Nov 22 16:09:55 2019 -0600
dma-buf: Fix memory leak in sync_file_merge()
commit 6645d42d79d33e8a9fe262660a75d5f4556bbea9 upstream.
In the implementation of sync_file_merge() the allocated sync_file is
leaked if number of fences overflows. Release sync_file by goto err.
Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct sync_file")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191122220957.30427-1-navid.emamdoost@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6344beb64054d8b9204b4167a0ae1f85439548a7
Author: Jiang Yi <giangyi@amazon.com>
Date: Wed Nov 27 17:49:10 2019 +0100
vfio/pci: call irq_bypass_unregister_producer() before freeing irq
commit d567fb8819162099035e546b11a736e29c2af0ea upstream.
Since irq_bypass_register_producer() is called after request_irq(), we
should do tear-down in reverse order: irq_bypass_unregister_producer()
then free_irq().
Specifically free_irq() may release resources required by the
irqbypass del_producer() callback. Notably an example provided by
Marc Zyngier on arm64 with GICv4 that he indicates has the potential
to wedge the hardware:
free_irq(irq)
__free_irq(irq)
irq_domain_deactivate_irq(irq)
its_irq_domain_deactivate()
[unmap the VLPI from the ITS]
kvm_arch_irq_bypass_del_producer(cons, prod)
kvm_vgic_v4_unset_forwarding(kvm, irq, ...)
its_unmap_vlpi(irq)
[Unmap the VLPI from the ITS (again), remap the original LPI]
Signed-off-by: Jiang Yi <giangyi@amazon.com>
Cc: stable@vger.kernel.org # v4.4+
Fixes: 6d7425f109d26 ("vfio: Register/unregister irq_bypass_producer")
Link: https://lore.kernel.org/kvm/20191127164910.15888-1-giangyi@amazon.com
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
[aw: commit log]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3362ea64bd352373765e4353e568be051ad2bf7
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Tue Jul 30 20:23:39 2019 +0300
ARM: tegra: Fix FLOW_CTLR_HALT register clobbering by tegra_resume()
commit d70f7d31a9e2088e8a507194354d41ea10062994 upstream.
There is an unfortunate typo in the code that results in writing to
FLOW_CTLR_HALT instead of FLOW_CTLR_CSR.
Cc: <stable@vger.kernel.org>
Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8856787db4f16aaa967690b4bbd5927bb8495a3
Author: Lihua Yao <ylhuajnu@outlook.com>
Date: Tue Sep 10 13:22:28 2019 +0000
ARM: dts: s3c64xx: Fix init order of clock providers
commit d60d0cff4ab01255b25375425745c3cff69558ad upstream.
fin_pll is the parent of clock-controller@7e00f000, specify
the dependency to ensure proper initialization order of clock
providers.
without this patch:
[ 0.000000] S3C6410 clocks: apll = 0, mpll = 0
[ 0.000000] epll = 0, arm_clk = 0
with this patch:
[ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
[ 0.000000] epll = 24000000, arm_clk = 532000000
Cc: <stable@vger.kernel.org>
Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ef23061cc4be085349525d3b60d92272d74f401a
Author: Paulo Alcantara (SUSE) <pc@cjr.nz>
Date: Fri Nov 22 12:30:56 2019 -0300
cifs: Fix retrieval of DFS referrals in cifs_mount()
commit 5bb30a4dd60e2a10a4de9932daff23e503f1dd2b upstream.
Make sure that DFS referrals are sent to newly resolved root targets
as in a multi tier DFS setup.
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Link: https://lkml.kernel.org/r/05aa2995-e85e-0ff4-d003-5bb08bd17a22@canonical.com
Cc: stable@vger.kernel.org
Tested-by: Matthew Ruffell <matthew.ruffell@canonical.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4324961126a6fa3e7e446fbf9b36ab1f2d63678a
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Thu Nov 21 11:35:13 2019 -0800
CIFS: Fix NULL pointer dereference in mid callback
commit 86a7964be7afaf3df6b64faaa10a7032d2444e51 upstream.
There is a race between a system call processing thread
and the demultiplex thread when mid->resp_buf becomes NULL
and later is being accessed to get credits. It happens when
the 1st thread wakes up before a mid callback is called in
the 2nd one but the mid state has already been set to
MID_RESPONSE_RECEIVED. This causes NULL pointer dereference
in mid callback.
Fix this by saving credits from the response before we
update the mid state and then use this value in the mid
callback rather then accessing a response buffer.
Cc: Stable <stable@vger.kernel.org>
Fixes: ee258d79159afed5 ("CIFS: Move credit processing to mid callbacks for SMB3")
Tested-by: Frank Sorenson <sorenson@redhat.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9871dea42034ee6e73bb2b97ba0284d3d462b230
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Thu Nov 21 11:35:14 2019 -0800
CIFS: Do not miss cancelled OPEN responses
commit 7b71843fa7028475b052107664cbe120156a2cfc upstream.
When an OPEN command is cancelled we mark a mid as
cancelled and let the demultiplex thread process it
by closing an open handle. The problem is there is
a race between a system call thread and the demultiplex
thread and there may be a situation when the mid has
been already processed before it is set as cancelled.
Fix this by processing cancelled requests when mids
are being destroyed which means that there is only
one thread referencing a particular mid. Also set
mids as cancelled unconditionally on their state.
Cc: Stable <stable@vger.kernel.org>
Tested-by: Frank Sorenson <sorenson@redhat.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 02e2d9deac95af8f687510d4c638683b7cbdf0c2
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Thu Nov 21 11:35:12 2019 -0800
CIFS: Close open handle after interrupted close
commit 9150c3adbf24d77cfba37f03639d4a908ca4ac25 upstream.
If Close command is interrupted before sending a request
to the server the client ends up leaking an open file
handle. This wastes server resources and can potentially
block applications that try to remove the file or any
directory containing this file.
Fix this by putting the close command into a worker queue,
so another thread retries it later.
Cc: Stable <stable@vger.kernel.org>
Tested-by: Frank Sorenson <sorenson@redhat.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1a935ec0a03928a3a1d021dc8a76ce04d98fe522
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date: Tue Nov 12 17:16:35 2019 -0800
CIFS: Respect O_SYNC and O_DIRECT flags during reconnect
commit 44805b0e62f15e90d233485420e1847133716bdc upstream.
Currently the client translates O_SYNC and O_DIRECT flags
into corresponding SMB create options when openning a file.
The problem is that on reconnect when the file is being
re-opened the client doesn't set those flags and it causes
a server to reject re-open requests because create options
don't match. The latter means that any subsequent system
call against that open file fail until a share is re-mounted.
Fix this by properly setting SMB create options when
re-openning files after reconnects.
Fixes: 1013e760d10e6: ("SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags")
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6c6eecb6cbd17d601fe486d5be8301346bfbbec4
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:50 2019 -0700
cifs: Don't display RDMA transport on reconnect
commit 14cc639c17ab0b6671526a7459087352507609e4 upstream.
On reconnect, the transport data structure is NULL and its information is not
available.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1c5a29621cf34b77d80d53d6728b9f90dbd250b
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:54 2019 -0700
cifs: smbd: Return -ECONNABORTED when trasnport is not in connected state
commit acd4680e2bef2405a0e1ef2149fbb01cce7e116c upstream.
The transport should return this error so the upper layer will reconnect.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 68dcbbd067e2873ac871722bc0a4586bd4648cab
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:52 2019 -0700
cifs: smbd: Return -EINVAL when the number of iovs exceeds SMBDIRECT_MAX_SGE
commit 37941ea17d3f8eb2f5ac2f59346fab9e8439271a upstream.
While it's not friendly to fail user processes that issue more iovs
than we support, at least we should return the correct error code so the
user process gets a chance to retry with smaller number of iovs.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 418968973e39b0e2aac29319f31dae33a52fd221
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:53 2019 -0700
cifs: smbd: Add messages on RDMA session destroy and reconnection
commit d63cdbae60ac6fbb2864bd3d8df7404f12b7407d upstream.
Log these activities to help production support.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 40d9bd5e51558512b8e31f0007b50503a3960881
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:55 2019 -0700
cifs: smbd: Only queue work for error recovery on memory registration
commit c21ce58eab1eda4c66507897207e20c82e62a5ac upstream.
It's not necessary to queue invalidated memory registration to work queue, as
all we need to do is to unmap the SG and make it usable again. This can save
CPU cycles in normal data paths as memory registration errors are rare and
normally only happens during reconnection.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 77d0084bde9c84331036093121f56345c8e765d3
Author: Long Li <longli@microsoft.com>
Date: Wed Oct 16 13:51:56 2019 -0700
cifs: smbd: Return -EAGAIN when transport is reconnecting
commit 4357d45f50e58672e1d17648d792f27df01dfccd upstream.
During reconnecting, the transport may have already been destroyed and is in
the process being reconnected. In this case, return -EAGAIN to not fail and
to retry this I/O.
Signed-off-by: Long Li <longli@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit adcd240d5cb688b8256045cf80849f1e8fa4a8f9
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Fri Oct 4 15:27:02 2019 -0700
rpmsg: glink: Free pending deferred work on remove
commit 278bcb7300f61785dba63840bd2a8cf79f14554c upstream.
By just cancelling the deferred rx worker during GLINK instance teardown
any pending deferred commands are leaked, so free them.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: stable@vger.kernel.org
Acked-by: Chris Lew <clew@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84afec146da361e7d17097e5ac1f8e8da0b3fe6e
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Fri Oct 4 15:27:01 2019 -0700
rpmsg: glink: Don't send pending rx_done during remove
commit c3dadc19b7564c732598b30d637c6f275c3b77b6 upstream.
Attempting to transmit rx_done messages after the GLINK instance is
being torn down will cause use after free and memory leaks. So cancel
the intent_work and free up the pending intents.
With this there are no concurrent accessors of the channel left during
qcom_glink_native_remove() and there is therefor no need to hold the
spinlock during this operation - which would prohibit the use of
cancel_work_sync() in the release function. So remove this.
Fixes: 1d2ea36eead9 ("rpmsg: glink: Add rx done command")
Cc: stable@vger.kernel.org
Acked-by: Chris Lew <clew@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7e682b1640543ceb5ee9500f8da82bf813f42da
Author: Chris Lew <clew@codeaurora.org>
Date: Fri Oct 4 15:27:00 2019 -0700
rpmsg: glink: Fix rpmsg_register_device err handling
commit f7e714988edaffe6ac578318e99501149b067ba0 upstream.
The device release function is set before registering with rpmsg. If
rpmsg registration fails, the framework will call device_put(), which
invokes the release function. The channel create logic does not need to
free rpdev if rpmsg_register_device() fails and release is called.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: stable@vger.kernel.org
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1cbc40a07c195617b9475a916a405d005fd49ad2
Author: Chris Lew <clew@codeaurora.org>
Date: Fri Oct 4 15:26:59 2019 -0700
rpmsg: glink: Put an extra reference during cleanup
commit b646293e272816dd0719529dcebbd659de0722f7 upstream.
In a remote processor crash scenario, there is no guarantee the remote
processor sent close requests before it went into a bad state. Remove
the reference that is normally handled by the close command in the
so channel resources can be released.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: stable@vger.kernel.org
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Chris Lew <clew@codeaurora.org>
Reported-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d375fb033a82ebbc7d0774618586785851c39c78
Author: Arun Kumar Neelakantam <aneela@codeaurora.org>
Date: Fri Oct 4 15:26:58 2019 -0700
rpmsg: glink: Fix use after free in open_ack TIMEOUT case
commit ac74ea01860170699fb3b6ea80c0476774c8e94f upstream.
Extra channel reference put when remote sending OPEN_ACK after timeout
causes use-after-free while handling next remote CLOSE command.
Remove extra reference put in timeout case to avoid use-after-free.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: stable@vger.kernel.org
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bee84d7d8b13926af3933cd054a734bf71ef3ad8
Author: Arun Kumar Neelakantam <aneela@codeaurora.org>
Date: Fri Oct 4 15:26:57 2019 -0700
rpmsg: glink: Fix reuse intents memory leak issue
commit b85f6b601407347f5425c4c058d1b7871f5bf4f0 upstream.
Memory allocated for re-usable intents are not freed during channel
cleanup which causes memory leak in system.
Check and free all re-usable memory to avoid memory leak.
Fixes: 933b45da5d1d ("rpmsg: glink: Add support for TX intents")
Cc: stable@vger.kernel.org
Acked-By: Chris Lew <clew@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Reported-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 06e60a45a429bcbe5be9eefb78b218382031f90e
Author: Chris Lew <clew@codeaurora.org>
Date: Wed Jun 27 18:19:57 2018 -0700
rpmsg: glink: Set tail pointer to 0 at end of FIFO
commit 4623e8bf1de0b86e23a56cdb39a72f054e89c3bd upstream.
When wrapping around the FIFO, the remote expects the tail pointer to
be reset to 0 on the edge case where the tail equals the FIFO length.
Fixes: caf989c350e8 ("rpmsg: glink: Introduce glink smem based transport")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bae1e47136ef7a61aab20018fd54176076433e3a
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Thu Nov 14 15:05:40 2019 -0800
xtensa: fix syscall_set_return_value
commit c2d9aa3b6e56de56c7f1ed9026ca6ec7cfbeef19 upstream.
syscall return value is in the register a2, not a0.
Cc: stable@vger.kernel.org # v5.0+
Fixes: 9f24f3c1067c ("xtensa: implement tracehook functions and enable HAVE_ARCH_TRACEHOOK")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 147128e77510ead2ca58311f3ff8e8472f2c154a
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Wed Nov 13 13:18:31 2019 -0800
xtensa: fix TLB sanity checker
commit 36de10c4788efc6efe6ff9aa10d38cb7eea4c818 upstream.
Virtual and translated addresses retrieved by the xtensa TLB sanity
checker must be consistent, i.e. correspond to the same state of the
checked TLB entry. KASAN shadow memory is mapped dynamically using
auto-refill TLB entries and thus may change TLB state between the
virtual and translated address retrieval, resulting in false TLB
insanity report.
Move read_xtlb_translation close to read_xtlb_virtual to make sure that
read values are consistent.
Cc: stable@vger.kernel.org
Fixes: a99e07ee5e88 ("xtensa: check TLB sanity on return to userspace")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0007f536dc968487b784e2269b0fdce1bd153f1c
Author: Bob Peterson <rpeterso@redhat.com>
Date: Thu Nov 14 09:49:11 2019 -0500
gfs2: fix glock reference problem in gfs2_trans_remove_revoke
commit fe5e7ba11fcf1d75af8173836309e8562aefedef upstream.
Commit 9287c6452d2b fixed a situation in which gfs2 could use a glock
after it had been freed. To do that, it temporarily added a new glock
reference by calling gfs2_glock_hold in function gfs2_add_revoke.
However, if the bd element was removed by gfs2_trans_remove_revoke, it
failed to drop the additional reference.
This patch adds logic to gfs2_trans_remove_revoke to properly drop the
additional glock reference.
Fixes: 9287c6452d2b ("gfs2: Fix occasional glock use-after-free")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e697fd14dbaf4a862be481658bba173bfab32892
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Thu Nov 7 18:06:14 2019 +0000
gfs2: Multi-block allocations in gfs2_page_mkwrite
commit f53056c43063257ae4159d83c425eaeb772bcd71 upstream.
In gfs2_page_mkwrite's gfs2_allocate_page_backing helper, try to
allocate as many blocks at once as we need. Pass in the size of the
requested allocation.
Fixes: 35af80aef99b ("gfs2: don't use buffer_heads in gfs2_allocate_page_backing")
Cc: stable@vger.kernel.org # v5.3+
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1948e76afc1202558d05bea5e2278f42b81cee10
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: Wed Nov 13 16:06:42 2019 -0800
xtensa: use MEMBLOCK_ALLOC_ANYWHERE for KASAN shadow map
commit e64681b487c897ec871465083bf0874087d47b66 upstream.
KASAN shadow map doesn't need to be accessible through the linear kernel
mapping, allocate its pages with MEMBLOCK_ALLOC_ANYWHERE so that high
memory can be used. This frees up to ~100MB of low memory on xtensa
configurations with KASAN and high memory.
Cc: stable@vger.kernel.org # v5.1+
Fixes: f240ec09bb8a ("memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc")
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 06ad673b6c585581a68e7b0059cf89ca9de67ab0
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Mon Dec 9 20:11:14 2019 +0100
block: fix "check bi_size overflow before merge"
commit cc90bc68422318eb8e75b15cd74bc8d538a7df29 upstream.
This partially reverts commit e3a5d8e386c3fb973fa75f2403622a8f3640ec06.
Commit e3a5d8e386c3 ("check bi_size overflow before merge") adds a bio_full
check to __bio_try_merge_page. This will cause __bio_try_merge_page to fail
when the last bi_io_vec has been reached. Instead, what we want here is only
the bi_size overflow check.
Fixes: e3a5d8e386c3 ("block: check bi_size overflow before merge")
Cc: stable@vger.kernel.org # v5.4+
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f092fa8da25146eacbc840340912282728d97814
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date: Tue Nov 26 17:17:11 2019 +0200
PM / QoS: Redefine FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX
commit c6a3aea93571a5393602256d8f74772bd64c8225 upstream.
QOS requests for DEFAULT_VALUE are supposed to be ignored but this is
not the case for FREQ_QOS_MAX. Adding one request for MAX_DEFAULT_VALUE
and one for a real value will cause freq_qos_read_value to unexpectedly
return MAX_DEFAULT_VALUE (-1).
This happens because freq_qos max value is aggregated with PM_QOS_MIN
but FREQ_QOS_MAX_DEFAULT_VALUE is (-1) so it's smaller than other
values.
Fix this by redefining FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX.
Looking at current users for freq_qos it seems that none of them create
requests for FREQ_QOS_MAX_DEFAULT_VALUE.
Fixes: 77751a466ebd ("PM: QoS: Introduce frequency QoS")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69396e4b317df12a87e35840bef2e94b9f827908
Author: George Cherian <george.cherian@marvell.com>
Date: Mon Nov 11 02:43:03 2019 +0000
PCI: Apply Cavium ACS quirk to ThunderX2 and ThunderX3
commit f338bb9f0179cb959977b74e8331b312264d720b upstream.
Enhance the ACS quirk for Cavium Processors. Add the root port vendor IDs
for ThunderX2 and ThunderX3 series of processors.
[bhelgaas: add Fixes: and stable tag]
Fixes: f2ddaf8dfd4a ("PCI: Apply Cavium ThunderX ACS quirk to more Root Ports")
Link: https://lore.kernel.org/r/20191111024243.GA11408@dc5-eodlnx05.marvell.com
Signed-off-by: George Cherian <george.cherian@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Robert Richter <rrichter@marvell.com>
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a67fc32eb9b6d4731f757309403181fd80b2c69
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Tue Nov 5 19:51:29 2019 +0900
PCI: rcar: Fix missing MACCTLR register setting in initialization sequence
commit 7c7e53e1c93df14690bd12c1f84730fef927a6f1 upstream.
The R-Car Gen2/3 manual - available at:
https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html#documents
"RZ/G Series User's Manual: Hardware" section
strictly enforces the MACCTLR inizialization value - 39.3.1 - "Initial
Setting of PCI Express":
"Be sure to write the initial value (= H'80FF 0000) to MACCTLR before
enabling PCIETCTLR.CFINIT".
To avoid unexpected behavior and to match the SW initialization sequence
guidelines, this patch programs the MACCTLR with the correct value.
Note that the MACCTLR.SPCHG bit in the MACCTLR register description
reports that "Only writing 1 is valid and writing 0 is invalid" but this
"invalid" has to be interpreted as a write-ignore aka "ignored", not
"prohibited".
Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver")
Fixes: be20bbcb0a8c ("PCI: rcar: Add the initialization of PCIe link in resume_noirq()")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 286a5249481a202d284dc2990c07bad074d71b1a
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Mon Nov 4 12:27:44 2019 +0530
PCI: Do not use bus number zero from EA capability
commit 73884a7082f466ce6686bb8dd7e6571dd42313b4 upstream.
As per PCIe r5.0, sec 7.8.5.2, fixed bus numbers of a bridge must be zero
when no function that uses EA is located behind it. Hence, if EA supplies
bus numbers of zero, assign bus numbers normally. A secondary bus can
never have a bus number of zero, so setting a bridge's Secondary Bus Number
to zero makes downstream devices unreachable.
[bhelgaas: retain bool return value so "zero is invalid" logic is local]
Fixes: 2dbce5901179 ("PCI: Assign bus numbers present in EA capability for bridges")
Link: https://lore.kernel.org/r/1572850664-9861-1-git-send-email-sundeep.lkml@gmail.com
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4d3d16fcbb81c4c8a5b2efd454a1a16c47921a1
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date: Tue Oct 8 11:42:39 2019 +0800
PCI/MSI: Fix incorrect MSI-X masking on resume
commit e045fa29e89383c717e308609edd19d2fd29e1be upstream.
When a driver enables MSI-X, msix_program_entries() reads the MSI-X Vector
Control register for each vector and saves it in desc->masked. Each
register is 32 bits and bit 0 is the actual Mask bit.
When we restored these registers during resume, we previously set the Mask
bit if *any* bit in desc->masked was set instead of when the Mask bit
itself was set:
pci_restore_state
pci_restore_msi_state
__pci_restore_msix_state
for_each_pci_msi_entry
msix_mask_irq(entry, entry->masked) <-- entire u32 word
__pci_msix_desc_mask_irq(desc, flag)
mask_bits = desc->masked & ~PCI_MSIX_ENTRY_CTRL_MASKBIT
if (flag) <-- testing entire u32, not just bit 0
mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT
writel(mask_bits, desc_addr + PCI_MSIX_ENTRY_VECTOR_CTRL)
This means that after resume, MSI-X vectors were masked when they shouldn't
be, which leads to timeouts like this:
nvme nvme0: I/O 978 QID 3 timeout, completion polled
On resume, set the Mask bit only when the saved Mask bit from suspend was
set.
This should remove the need for 19ea025e1d28 ("nvme: Add quirk for Kingston
NVME SSD running FW E8FK11.T").
[bhelgaas: commit log, move fix to __pci_msix_desc_mask_irq()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Link: https://lore.kernel.org/r/20191008034238.2503-1-jian-hong@endlessm.com
Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c6a922cf8a102962358bd97d5e1b50b35ee4910
Author: Steffen Liebergeld <steffen.liebergeld@kernkonzept.com>
Date: Wed Sep 18 15:16:52 2019 +0200
PCI: Fix Intel ACS quirk UPDCR register address
commit d8558ac8c93d429d65d7490b512a3a67e559d0d4 upstream.
According to documentation [0] the correct offset for the Upstream Peer
Decode Configuration Register (UPDCR) is 0x1014. It was previously defined
as 0x1114.
d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports")
intended to enforce isolation between PCI devices allowing them to be put
into separate IOMMU groups. Due to the wrong register offset the intended
isolation was not fully enforced. This is fixed with this patch.
Please note that I did not test this patch because I have no hardware that
implements this register.
[0] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-i-o-datasheet.pdf (page 325)
Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports")
Link: https://lore.kernel.org/r/7a3505df-79ba-8a28-464c-88b83eefffa6@kernkonzept.com
Signed-off-by: Steffen Liebergeld <steffen.liebergeld@kernkonzept.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Acked-by: Ashok Raj <ashok.raj@intel.com>
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9bd9d123399b7f02a9c05d0b63b1abeb8840c94f
Author: Lukas Wunner <lukas@wunner.de>
Date: Fri Aug 9 12:28:43 2019 +0200
PCI: pciehp: Avoid returning prematurely from sysfs requests
commit 157c1062fcd86ade3c674503705033051fd3d401 upstream.
A sysfs request to enable or disable a PCIe hotplug slot should not
return before it has been carried out. That is sought to be achieved by
waiting until the controller's "pending_events" have been cleared.
However the IRQ thread pciehp_ist() clears the "pending_events" before
it acts on them. If pciehp_sysfs_enable_slot() / _disable_slot() happen
to check the "pending_events" after they have been cleared but while
pciehp_ist() is still running, the functions may return prematurely
with an incorrect return value.
Fix by introducing an "ist_running" flag which must be false before a sysfs
request is allowed to return.
Fixes: 32a8cef274fe ("PCI: pciehp: Enable/disable exclusively from IRQ thread")
Link: https://lore.kernel.org/linux-pci/1562226638-54134-1-git-send-email-wangxiongfeng2@huawei.com
Link: https://lore.kernel.org/r/4174210466e27eb7e2243dd1d801d5f75baaffd8.1565345211.git.lukas@wunner.de
Reported-and-tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01acd9e82f8291f1a7755537e695368ce6567207
Author: Dexuan Cui <decui@microsoft.com>
Date: Wed Aug 14 01:06:55 2019 +0000
PCI/PM: Always return devices to D0 when thawing
commit f2c33ccacb2d4bbeae2a255a7ca0cbfd03017b7c upstream.
pci_pm_thaw_noirq() is supposed to return the device to D0 and restore its
configuration registers, but previously it only did that for devices whose
drivers implemented the new power management ops.
Hibernation, e.g., via "echo disk > /sys/power/state", involves freezing
devices, creating a hibernation image, thawing devices, writing the image,
and powering off. The fact that thawing did not return devices with legacy
power management to D0 caused errors, e.g., in this path:
pci_pm_thaw_noirq
if (pci_has_legacy_pm_support(pci_dev)) # true for Mellanox VF driver
return pci_legacy_resume_early(dev) # ... legacy PM skips the rest
pci_set_power_state(pci_dev, PCI_D0)
pci_restore_state(pci_dev)
pci_pm_thaw
if (pci_has_legacy_pm_support(pci_dev))
pci_legacy_resume
drv->resume
mlx4_resume
...
pci_enable_msix_range
...
if (dev->current_state != PCI_D0) # <---
return -EINVAL;
which caused these warnings:
mlx4_core a6d1:00:02.0: INTx is not supported in multi-function mode, aborting
PM: dpm_run_callback(): pci_pm_thaw+0x0/0xd7 returns -95
PM: Device a6d1:00:02.0 failed to thaw: error -95
Return devices to D0 and restore config registers for all devices, not just
those whose drivers support new power management.
[bhelgaas: also call pci_restore_state() before pci_legacy_resume_early(),
update comment, add stable tag, commit log]
Link: https://lore.kernel.org/r/KU1P153MB016637CAEAD346F0AA8E3801BFAD0@KU1P153MB0166.APCP153.PROD.OUTLOOK.COM
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d83f65da65e07dad759ccc6125f63e88ea23cc8e
Author: Logan Gunthorpe <logang@deltatee.com>
Date: Tue Sep 10 13:58:33 2019 -0600
PCI/switchtec: Read all 64 bits of part_event_bitmap
commit 6acdf7e19b37cb3a9258603d0eab315079c19c5e upstream.
The part_event_bitmap register is 64 bits wide, so read it with ioread64()
instead of the 32-bit ioread32().
Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Link: https://lore.kernel.org/r/20190910195833.3891-1-logang@deltatee.com
Reported-by: Doug Meyer <dmeyer@gigaio.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v4.12+
Cc: Kelvin Cao <Kelvin.Cao@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1a35dfb2a1fd1e6d33fbc7a8a6011b7b7160605f
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Thu Oct 17 15:25:36 2019 +0200
mmc: core: Re-work HW reset for SDIO cards
commit 2ac55d5e5ec9ad0a07e194f0eaca865fe5aa3c40 upstream.
It have turned out that it's not a good idea to unconditionally do a power
cycle and then to re-initialize the SDIO card, as currently done through
mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple
SDIO func drivers probed, who also shares the same SDIO card.
To address these scenarios, one may be tempted to use a notification
mechanism, as to allow the core to inform each of the probed func drivers,
about an ongoing HW reset. However, supporting such an operation from the
func driver point of view, may not be entirely trivial.
Therefore, let's use a more simplistic approach to solve the problem, by
instead forcing the card to be removed and re-detected, via scheduling a
rescan-work. In this way, we can rely on existing infrastructure, as the
func driver's ->remove() and ->probe() callbacks, becomes invoked to deal
with the cleanup and the re-initialization.
This solution may be considered as rather heavy, especially if a func
driver doesn't share its card with other func drivers. To address this,
let's keep the current immediate HW reset option as well, but run it only
when there is one func driver probed for the card.
Finally, to allow the caller of mmc_hw_reset(), to understand if the reset
is being asynchronously managed from a scheduled work, it returns 1
(propagated from mmc_sdio_hw_reset()). If the HW reset is executed
successfully and synchronously it returns 0, which maintains the existing
behaviour.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0b50e5c4f396f5c2bef3ad528f3b3d4d186fed1
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Thu Oct 10 15:54:37 2019 +0200
mmc: core: Drop check for mmc_card_is_removable() in mmc_rescan()
commit 99b4ddd8b76a6f60a8c2b3775849d65d21a418fc upstream.
Upfront in mmc_rescan() we use the host->rescan_entered flag, to allow
scanning only once for non-removable cards. Therefore, it's also not
possible that we can have a corresponding card bus attached (host->bus_ops
is NULL), when we are scanning non-removable cards.
For this reason, let' drop the check for mmc_card_is_removable() as it's
redundant.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89c6e88294693dbbbd3d94f22940320f67f7792d
Author: Chaotian Jing <chaotian.jing@mediatek.com>
Date: Thu Sep 5 15:53:18 2019 +0800
mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response
commit a0d4c7eb71dd08a89ad631177bb0cbbabd598f84 upstream.
MMC IOCTLS with R1B responses may cause the card to enter the busy state,
which means it's not ready to receive a new request. To prevent new
requests from being sent to the card, use a CMD13 polling loop to verify
that the card returns to the transfer state, before completing the request.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0cc2b0e6e5b6b9ff105115ce4d6dfdb2c8165b27
Author: Chaotian Jing <chaotian.jing@mediatek.com>
Date: Thu Sep 5 15:53:17 2019 +0800
mmc: block: Make card_busy_detect() a bit more generic
commit 3869468e0c4800af52bfe1e0b72b338dcdae2cfc upstream.
To prepare for more users of card_busy_detect(), let's drop the struct
request * as an in-parameter and convert to log the error message via
dev_err() instead of pr_err().
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b39b507a1539124e780745b2480de7386fc18c5
Author: Fredrik Noring <noring@nocrew.org>
Date: Tue Dec 10 18:29:05 2019 +0100
USB: Fix incorrect DMA allocations for local memory pool drivers
commit f8c63edfd78905320e86b6b2be2b7a5ac768fa4e upstream.
Fix commit 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of
guestimating DMA capabilities") where local memory USB drivers
erroneously allocate DMA memory instead of pool memory, causing
OHCI Unrecoverable Error, disabled
HC died; cleaning up
The order between hcd_uses_dma() and hcd->localmem_pool is now
arranged as in hcd_buffer_alloc() and hcd_buffer_free(), with the
test for hcd->localmem_pool placed first.
As an alternative, one might consider adjusting hcd_uses_dma() with
static inline bool hcd_uses_dma(struct usb_hcd *hcd)
{
- return IS_ENABLED(CONFIG_HAS_DMA) && (hcd->driver->flags & HCD_DMA);
+ return IS_ENABLED(CONFIG_HAS_DMA) &&
+ (hcd->driver->flags & HCD_DMA) &&
+ (hcd->localmem_pool == NULL);
}
One can also consider unsetting HCD_DMA for local memory pool drivers.
Fixes: 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Fredrik Noring <noring@nocrew.org>
Link: https://lore.kernel.org/r/20191210172905.GA52526@sx9
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>