Surprisingly many places depend on debugfs.h to be included via
drm_print.h. Fix them.
v2: Also fix ivpu and vmwgfx
Reviewed-by: Andrzej Hajda
Acked-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-1-jani.nik...@intel.com
Signed-off-by: Jani Nikula
On Thu, Apr 18, 2024 at 03:19:46AM +, wangzhu wrote:
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch to fix it, its commit
> is 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB
>
Hey Jani,
Thanks for doing this cleanup.
On Thu, Apr 18, 2024 at 12:13 PM Jani Nikula wrote:
>
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v2: Also fix ivpu and vmwgfx
>
> Reviewed-by: Andrzej Hajda
> Acked-by: Maxime Ripard
> Link:
>
This patch series implement new KFD memory alloc flag for best effort contiguous
VRAM allocation, to support peer direct access RDMA device with limited
scatter-gather
dma capability.
v2: rebase on patch ("drm/amdgpu: Modify the contiguous flags behaviour")
to avoid adding the new GEM flag
When TTM failed to alloc VRAM, TTM try evict BOs from VRAM to system
memory then retry the allocation, this skips the KFD BOs from the same
process because KFD require all BOs are resident for user queues.
If TTM with TTM_PL_FLAG_CONTIGUOUS flag to alloc contiguous VRAM, allow
TTM evict KFD BOs
TTM allocate contiguous VRAM may takes more than 1 second to evict BOs
for larger size RDMA buffer. Because KFD restore bo worker reserves all
KFD BOs, then TTM cannot hold the remainning KFD BOs lock to evict them,
this causes TTM failed to alloc contiguous VRAM.
Increase the KFD restore BO wait
Bump the kfd ioctl minor version to delcare the contiguous VRAM
allocation flag support.
Signed-off-by: Philip Yang
---
include/uapi/linux/kfd_ioctl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index
To test RDMA using dummy driver on the system without NIC/RDMA
device, the get/put dma pages pass in null device pointer, skip the
dma map/unmap resource to avoid null pointer access.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 33 +++-
1 file
RDMA device with limited scatter-gather ability requires contiguous VRAM
buffer allocation for RDMA peer direct support.
Add a new KFD alloc memory flag and store as bo alloc flag
AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS. When pin this bo to export for RDMA
peerdirect access, this will set
If the BO pages pinned for RDMA is not contiguous on VRAM, evict it to
system memory first to free the VRAM space, then allocate contiguous
VRAM space, and then move it from system memory back to VRAM.
Signed-off-by: Philip Yang
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c| 17
[AMD Official Use Only - General]
-
Best Regards,
Thomas
-Original Message-
From: Christian König
Sent: Thursday, April 18, 2024 5:01 PM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas ; Zhang, Hawking ;
Zhou1, Tao ; Li, Candice ; Wang,
Yang(Kevin) ;
On Wed, Apr 17, 2024 at 11:14 PM wangzhu wrote:
>
> The CVE-2023-52624 is fixed in linux-6.7 stable, while it is not fixed in
> 6.6, this commit is presented to fix it in linux-6.6 stable.
Why is there a CVE in the first place? Is this actually an issue you
have seen? It seems like you just
On Thu, Mar 21, 2024 at 10:37 AM Christian König
wrote:
>
> Am 21.03.24 um 15:12 schrieb Tvrtko Ursulin:
> >
> > On 21/03/2024 12:43, Christian König wrote:
> >> This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move
> >> on same heap. The basic problem here is that after the move
On 2024-03-07 01:29, Wayne Lin wrote:
> [Why]
> Commit:
> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> allocation/removement")
> accidently overwrite the commit
> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
> drm_dp_add_payload_part2")
> which cause
Free the sync object if the memory allocation fails for any
reason.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Mukul Joshi
Sent: Thursday, April 18, 2024 12:17 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Joshi, Mukul
Subject: [PATCH] drm/amdgpu: Fix leak when GPU memory allocation fails
Am 18.04.24 um 15:57 schrieb Philip Yang:
RDMA device with limited scatter-gather ability requires contiguous VRAM
buffer allocation for RDMA peer direct support.
Add a new KFD alloc memory flag and store as bo alloc flag
AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS. When pin this bo to export for RDMA
On 2024-04-17 15:53, Alex Deucher wrote:
Makes it easier to review the logs when there are MES
errors.
v2: use dbg for emitted, add helpers for fetching strings
v3: fix missing commas (Harish)
Reviewed by Shaoyun.liu (v2)
Signed-off-by: Alex Deucher
---
[AMD Official Use Only - General]
I think the only user for the MES is kernel driver and all the submission to
MES need to be synced , driver already have the mes->ring_lock to ensure
that . I don't know why there is a necessary to use separate fence per request .
MES do update the API
On Thu, Apr 18, 2024 at 2:22 PM Pierre-Eric Pelloux-Prayer
wrote:
>
> Init r to 0 to avoid returning an uninitialized value if we never
> enter the loop. This case should never be hit in practive, but
s/practive/practice/
> returning 0 doesn't hurt.
s/returning/initializing to/
With that
Make SVM BOs more likely to get evicted than other BOs. These BOs
opportunistically use available VRAM, but can fall back relatively
seamlessly to system memory. It also avoids SVM migrations evicting
other, more important BOs as they will evict other SVM allocations
first.
Signed-off-by: Felix
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7b4f2bc91c15fdcf948bb2d9741a9d7d54303f8d Add linux-next specific
files for 20240418
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404190103.llm8ltup-...@intel.com
Error
On 2024-04-17 23:14, Felix Kuehling
wrote:
Handle case that dma_fence_get_rcu_safe returns NULL.
If restore work is already scheduled, only update its timer. The same
work item cannot be queued twice, so undo the extra queue eviction.
Fixes: 9a1c1339abf9
Init r to 0 to avoid returning an uninitialized value if we never
enter the loop. This case should never be hit in practive, but
returning 0 doesn't hurt.
The same fix is applied to the 4 places using the same pattern.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
[AMD Official Use Only - General]
Tested-by: Gang BA
Reviewed-by: Gang BA
From: Kuehling, Felix
Sent: Wednesday, April 17, 2024 11:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Ba, Gang ; Prosyak, Vitaly
Subject: [PATCH] drm/amdkfd: Fix eviction fence handling
[AMD Official Use Only - General]
Tested-by and Acked-by: Mukul Joshi
> -Original Message-
> From: amd-gfx On Behalf Of Felix
> Kuehling
> Sent: Thursday, April 18, 2024 2:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Joshi, Mukul ; Koenig, Christian
>
> Subject: [PATCH] drm/amdgpu:
On 2024-04-11 4:11, Lang Yu wrote:
When page table BOs were evicted but not validated before
updating page tables, VM is still in evicting state,
amdgpu_vm_update_range returns -EBUSY and
restore_process_worker runs into a dead loop.
v2: Split the BO validation and page table update into
two
On 2024-04-18 10:37, Christian König
wrote:
Am 18.04.24 um 15:57 schrieb Philip Yang:
RDMA device with limited scatter-gather
ability requires contiguous VRAM
buffer allocation for RDMA peer direct support.
[AMD Official Use Only - General]
Acked-by: Alex Deucher
From: Lee, Peyton
Sent: Thursday, April 18, 2024 1:12 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, HaoPing (Alan)
; Yu, Lang ; Lee, Peyton
Subject: [PATCH] drm/amdgpu/vpe: fix vpe
[Public]
Reviewed-by: Lang Yu
>-Original Message-
>From: Lee, Peyton
>Sent: Thursday, April 18, 2024 1:13 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Liu, HaoPing (Alan)
>; Yu, Lang ; Lee, Peyton
>
>Subject: [PATCH] drm/amdgpu/vpe: fix vpe dpm setup failed
>
>The
From: Arnd Bergmann
This structure is too large to fit on a stack, as shown by the
newly introduced warnings from a recent code change:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In
function 'dcn32_update_bw_bounding_box':
From: Arnd Bergmann
The graphics_object_id structure is meant to fit into 32 bits, as it's
passed by value in and out of functions. A recent change increased
the size to 128 bits, so it's now always passed by reference, which
is clearly not intended and ends up producing a compile-time warning:
Am 17.04.24 um 17:45 schrieb Alex Deucher:
On Wed, Apr 17, 2024 at 5:38 AM Sunil Khatri wrote:
Add the prototype to dump ip registers
for all ips of different asics and set
them to NULL for now. Based on the
requirement add a function pointer for
each of them.
Signed-off-by: Sunil Khatri
---
Am 18.04.24 um 04:58 schrieb YiPeng Chai:
Use new interface to reserve bad page.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
in linux-5.10, there is a patch in the linux-6.7 branch to fix it, its commit
is 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB
before executing GPINT commands"). When we apply this patch to
Hi Mario,
On Thu, Feb 15, 2024 at 8:04 PM Mario Limonciello
wrote:
> On 2/15/2024 12:47, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> >> On 2/14/2024 17:13, Ville Syrjälä wrote:
> >>> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello
On Thu, Apr 18, 2024 at 01:51:33AM +, wangzhu wrote:
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
> 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
>
The CVE-2023-52624 is fixed in linux-6.7 stable, while it is not fixed in 6.6,
this commit is presented to fix it in linux-6.6 stable.
-邮件原件-
发件人: Alex Deucher [mailto:alexdeuc...@gmail.com]
发送时间: 2024年4月18日 9:58
收件人: wangzhu
抄送: Greg KH ; harry.wentl...@amd.com;
sunpeng...@amd.com;
Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
executing GPINT commands"). When we apply this patch to linux-5.10,
Am 17.04.24 um 19:30 schrieb Alex Deucher:
On Wed, Apr 17, 2024 at 1:01 PM Khatri, Sunil wrote:
On 4/17/2024 10:21 PM, Alex Deucher wrote:
On Wed, Apr 17, 2024 at 12:24 PM Lazar, Lijo wrote:
[AMD Official Use Only - General]
Yes, right now that API doesn't return anything. What I meant is
40 matches
Mail list logo
