linux-stable.git/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c, branch linux-5.4.y Linux kernel stable tree drm/amdkfd: Walk through list with dqm lock hold 2021-07-19T06:53:11+00:00 xinhui pan xinhui.pan@amd.com 2021-06-15T07:11:07+00:00 356bb9411a26955a93ac1a366f3e6885a2f78ca4 [ Upstream commit 56f221b6389e7ab99c30bbf01c71998ae92fc584 ] To avoid any list corruption. Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 56f221b6389e7ab99c30bbf01c71998ae92fc584 ]

To avoid any list corruption.

Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning 2021-05-11T12:04:09+00:00 Anson Jacob Anson.Jacob@amd.com 2021-03-03T17:33:15+00:00 0c0356ef2498c1a250fe3846f30293f828737309 [ Upstream commit 50e2fc36e72d4ad672032ebf646cecb48656efe0 ] If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up doing a shift operation where the number of bits shifted equals number of bits in the operand. This behaviour is undefined. Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the count is >= number of bits in the operand. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472 Reported-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Anson Jacob <Anson.Jacob@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Tested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 50e2fc36e72d4ad672032ebf646cecb48656efe0 ]

If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.

Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

Reported-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Tested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdkfd: fix a memory leak issue 2020-10-01T11:18:15+00:00 Dennis Li Dennis.Li@amd.com 2020-09-02T09:11:09+00:00 c48363d19fcbbcfbef23e3daff3fd33df70c4a29 [ Upstream commit 087d764159996ae378b08c0fdd557537adfd6899 ] In the resume stage of GPU recovery, start_cpsch will call pm_init which set pm->allocated as false, cause the next pm_release_ib has no chance to release ib memory. Add pm_release_ib in stop_cpsch which will be called in the suspend stage of GPU recovery. Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Dennis Li <Dennis.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 087d764159996ae378b08c0fdd557537adfd6899 ]

In the resume stage of GPU recovery, start_cpsch will call pm_init
which set pm->allocated as false, cause the next pm_release_ib has
no chance to release ib memory.

Add pm_release_ib in stop_cpsch which will be called in the suspend
stage of GPU recovery.

Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Dennis Li <Dennis.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode 2020-02-24T07:36:32+00:00 Yong Zhao Yong.Zhao@amd.com 2020-01-30T00:55:47+00:00 25c85d8574d8e4466a6334325a5ab5a3aab3c4c2 [ Upstream commit f38abc15d157b7b31fa7f651dc8bf92858c963f8 ] The sdma_queue_count increment should be done before execute_queues_cpsch(), which calls pm_calc_rlib_size() where sdma_queue_count is used to calculate whether over_subscription is triggered. With the previous code, when a SDMA queue is created, compute_queue_count in pm_calc_rlib_size() is one more than the actual compute queue number, because the queue_count has been incremented while sdma_queue_count has not. This patch fixes that. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f38abc15d157b7b31fa7f651dc8bf92858c963f8 ]

The sdma_queue_count increment should be done before
execute_queues_cpsch(), which calls pm_calc_rlib_size() where
sdma_queue_count is used to calculate whether over_subscription is
triggered.

With the previous code, when a SDMA queue is created,
compute_queue_count in pm_calc_rlib_size() is one more than the
actual compute queue number, because the queue_count has been
incremented while sdma_queue_count has not. This patch fixes that.

Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdkfd: Fix MQD size calculation 2019-12-31T15:43:47+00:00 Oak Zeng Oak.Zeng@amd.com 2019-10-04T14:28:21+00:00 be30e550a54c4b088a0b6f4e1ac4b27b72decd41 [ Upstream commit 40a9592a26608e16f7545a068ea4165e1869f629 ] On device initialization, a chunk of GTT memory is pre-allocated for HIQ and all SDMA queues mqd. The size of this allocation was wrong. The correct sdma engine number should be PCIe-optimized SDMA engine number plus xgmi SDMA engine number. Reported-by: Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 40a9592a26608e16f7545a068ea4165e1869f629 ]

On device initialization, a chunk of GTT memory is pre-allocated for
HIQ and all SDMA queues mqd. The size of this allocation was wrong.
The correct sdma engine number should be PCIe-optimized SDMA engine
number plus xgmi SDMA engine number.

Reported-by: Jonathan Kim <Jonathan.Kim@amd.com>
Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com>
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdkfd: Make deallocate_hiq_sdma_mqd static 2019-08-22T22:25:10+00:00 YueHaibing yuehaibing@huawei.com 2019-05-25T12:51:09+00:00 7fd5a6fb9a75cc00479a7ad4305b5ab31ae2cd59 Fix sparse warning: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:1846:6: warning: symbol 'deallocate_hiq_sdma_mqd' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Fix sparse warning:

drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:1846:6:
 warning: symbol 'deallocate_hiq_sdma_mqd' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdkfd: Fix sdma_bitmap overflow issue 2019-07-18T19:18:04+00:00 Oak Zeng Oak.Zeng@amd.com 2019-07-09T14:40:15+00:00 35cdc81bfa94d10373ecae279f3c48ca858ac4fd In the original formula, when sdma queue number is 64, the left shift overflows. Use an equivalence that won't overflow. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
In the original formula, when sdma queue number is 64,
the left shift overflows. Use an equivalence that won't
overflow.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amd/amdkfd: Add ASIC ARCTURUS to kfd 2019-07-18T19:18:03+00:00 Yong Zhao Yong.Zhao@amd.com 2019-07-09T14:37:04+00:00 49adcf8a6f951450417c14afa6a404b7caea25ef Add initial support for ARCTURUS to kfd. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Add initial support for ARCTURUS to kfd.

Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdkfd: fix cp hang in eviction 2019-07-11T19:37:24+00:00 Eric Huang JinhuiEric.Huang@amd.com 2019-07-09T19:33:53+00:00 70df8273ca0cebd2bba443a4444b4944a5929151 The cp hang occurs in OCL conformance test only on supermicro platform which has 40 cores and the test generates 40 threads. The root cause is race condition in non-protected flags. The fix is to add flags of is_evicted and is_active(init_mqd()) into protected area. Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
The cp hang occurs in OCL conformance test only on supermicro
platform which has 40 cores and the test generates 40 threads.
The root cause is race condition in non-protected flags.

The fix is to add flags of is_evicted and is_active(init_mqd())
into protected area.

Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdkfd: Set gws_mask to 64 bit 1s 2019-06-22T14:34:14+00:00 Oak Zeng Oak.Zeng@amd.com 2019-06-14T15:55:50+00:00 d9848e149da1ac98bf1220a4fe5977c5bfeca7ef Previous kfd doesn't use gws so this mask was set to 0. Set it to 64 bit 1s because now kfd can use all 64 gws resources. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 
Previous kfd doesn't use gws so this mask was set to 0.
Set it to 64 bit 1s because now kfd can use all 64 gws
resources.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>