Adding Pierre-eric and Tvrtko as well.
Am 11.04.25 um 15:04 schrieb Sunil Khatri:
> Add helper function which get the process information for
> the drm_file and updates the user provided character buffer
> with the information of process name and pid as a string.
>
> Signed-off-by: Sunil Khatri
>
Adding Pierre-eric and Tvrtko as well.
Am 11.04.25 um 15:04 schrieb Sunil Khatri:
> Add helper function which get the process information for
> the drm_file and updates the user provided character buffer
> with the information of process name and pid as a string.
>
> Signed-off-by: Sunil Khatri
>
> Libdrm MR: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/408
> Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34493
>
> Signed-off-by: Arunpravin Paneer Selvam
> Suggested-by: Christian König
Reviewed-by: Christian König
Coming back to the original patch.
Am 08.04.25 um 11:17 schrieb Denis Arefev:
> The user can set any value to the variable ‘bo_number’, via the ioctl
> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect the arithmetic
> expression ‘in->bo_number * in->bo_info_size’, which is prone to
> overflow. A
Am 13.04.25 um 13:31 schrieb Fedor Pchelkin:
> On Thu, 10. Apr 11:07, Christian König wrote:
>> Am 09.04.25 um 19:27 schrieb Linus Torvalds:
>>> The VM layer allows larger allocations. But the "this is a simple
>>> allocation, choose kmalloc or vmalloc automaticall
Am 13.04.25 um 13:31 schrieb Fedor Pchelkin:
> On Thu, 10. Apr 11:07, Christian König wrote:
>> Am 09.04.25 um 19:27 schrieb Linus Torvalds:
>>> The VM layer allows larger allocations. But the "this is a simple
>>> allocation, choose kmalloc or vmalloc automaticall
Coming back to the original patch.
Am 08.04.25 um 11:17 schrieb Denis Arefev:
> The user can set any value to the variable ‘bo_number’, via the ioctl
> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect the arithmetic
> expression ‘in->bo_number * in->bo_info_size’, which is prone to
> overflow. A
Am 14.04.25 um 10:24 schrieb Thomas Petazzoni:
> Hello Christoph,
>
> On Sun, 13 Apr 2025 22:55:02 -0700
> Christoph Hellwig wrote:
>
>> On Thu, Apr 10, 2025 at 04:53:17PM +0200, Bastien Curutchet wrote:
>>> Hi all,
>>>
>>> Many UIO users performing DMA from their UIO device need to access the
>>>
Am 14.04.25 um 10:17 schrieb Thomas Petazzoni:
> Hello Christian,
>
> On Fri, 11 Apr 2025 14:41:56 +0200
> Christian König wrote:
>
>> But anyway please note that when you want to create new UAPI you need
>> to provide an open source user of it. E.g. link to a reposit
Am 11.04.25 um 14:44 schrieb Philipp Stanner:
> On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote:
>> Am 11.04.25 um 11:29 schrieb Philipp Stanner:
>>
>>> [SNIP]
>>>
>>> It could be, however, that at the same moment
>>> nouveau_fen
Am 11.04.25 um 13:26 schrieb Sunil Khatri:
> Add helper function which get the process information for
> the drm_file and updates the user provided character buffer
> with the information of process name and pid as a string.
Hi Sunil,
you need to send this out together with the patch which makes
Am 11.04.25 um 16:20 schrieb Alex Deucher:
> Not techincally wrong, but I think a semicolon was
> intended here.
>
> Fixes: 6cc6e61788f7 ("drm/amdgpu: use a dummy owner for sysfs triggered
> cleaner shaders v3")
> Cc: Christian König
> Signed-off-by: Alex Deucher
last_update = vm->last_update;
> 138 else
> --> 139 last_update = bo_va->last_pt_update;
> ^ This pointer is
> dereferenced without being checked.
>
> 140 break;
>
> Fi
Am 11.04.25 um 15:00 schrieb Boris Brezillon:
> On Fri, 11 Apr 2025 14:45:49 +0200
> Christian König wrote:
>
>> Am 11.04.25 um 14:02 schrieb Boris Brezillon:
>>>>> I guess this leaves older GPUs that don't support incremental
>>>>> renderi
Hi Bastien,
Am 11.04.25 um 10:14 schrieb Bastien Curutchet:
> Hi Christian,
>
> On 4/11/25 9:30 AM, Christian König wrote:
>> Hi Thomas,
>>
>> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
>>> Hello Christian,
>>>
>>> Thanks for you
fix the logic
v6: separate cleaner shader checks as suggested by Srini
Signed-off-by: Christian König
Reviewed-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 106 ++---
drivers/gpu/drm/amd/amdgpu
e_private,
>> dma_fence_put(fence);
>> drm_syncobj_put(syncobj);
>> return 0;
>> +
>> +err_put_syncobj:
>> + drm_syncobj_put(syncobj);
>> +err_put_fence:
>> + dma_fence_put(fence);
>> +
>> + return ret;
> I suppose you could just initialize ret to zero and collapse the two
> return paths? Either way,
Yep, good point.
With that done Reviewed-by: Christian König as well.
Regards,
Christian.
>
> Reviewed-by: Rob Clark
>
>> }
>>
>> static int drm_syncobj_export_sync_file(struct drm_file *file_private,
>> --
>> 2.47.2
>>
Am 08.04.25 um 13:01 schrieb Dan Carpenter:
> Call dma_fence_put(fence) before returning an error if
> dma_fence_to_sync_pt() fails. Use an unwind ladder at the
> end of the function to do the cleanup.
>
> Fixes: 70e67aaec2f4 ("dma-buf/sw_sync: Add fence deadline support")
> Signed-off-by: Dan Car
Am 11.04.25 um 14:44 schrieb Philipp Stanner:
> On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote:
>> Am 11.04.25 um 11:29 schrieb Philipp Stanner:
>>
>>> [SNIP]
>>>
>>> It could be, however, that at the same moment
>>> nouveau_fen
Am 11.04.25 um 14:01 schrieb Simona Vetter:
> On Thu, Apr 10, 2025 at 08:41:55PM +0200, Boris Brezillon wrote:
>> On Thu, 10 Apr 2025 14:01:03 -0400
>> Alyssa Rosenzweig wrote:
>>
>> In Panfrost and Lima, we don't have this concept of "incremental
>> rendering", so when we fail the allocat
Am 11.04.25 um 14:02 schrieb Boris Brezillon:
>>> I guess this leaves older GPUs that don't support incremental
>>> rendering in a bad place though.
>> Well what's the handling there currently? Just crash when you're OOM?
> It's "alloc(GFP_KERNEL) and crash if it fails or times out", yes.
Oh, pl
Am 11.04.25 um 13:26 schrieb Sunil Khatri:
> Add helper function which get the process information for
> the drm_file and updates the user provided character buffer
> with the information of process name and pid as a string.
Hi Sunil,
you need to send this out together with the patch which makes
Am 11.04.25 um 11:29 schrieb Philipp Stanner:
> [SNIP]
> It could be, however, that at the same moment nouveau_fence_signal() is
> removing that entry, holding the appropriate lock.
>
> So we have a race. Again.
Ah, yes of course. If signaled is called with or without the lock is actually
undeter
Am 11.04.25 um 11:29 schrieb Philipp Stanner:
> [SNIP]
> It could be, however, that at the same moment nouveau_fence_signal() is
> removing that entry, holding the appropriate lock.
>
> So we have a race. Again.
Ah, yes of course. If signaled is called with or without the lock is actually
undeter
Am 11.04.25 um 10:38 schrieb Boris Brezillon:
> On Fri, 11 Apr 2025 10:04:07 +0200
> Christian König wrote:
>
>> Am 10.04.25 um 20:41 schrieb Boris Brezillon:
>>> On Thu, 10 Apr 2025 14:01:03 -0400
>>> Alyssa Rosenzweig wrote:
>>>
>>>>&
Am 10.04.25 um 20:41 schrieb Boris Brezillon:
> On Thu, 10 Apr 2025 14:01:03 -0400
> Alyssa Rosenzweig wrote:
>
> In Panfrost and Lima, we don't have this concept of "incremental
> rendering", so when we fail the allocation, we just fail the GPU job
> with an unhandled GPU fault.
>
Hi Thomas,
Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
> Hello Christian,
>
> Thanks for your feedback!
>
> On Thu, 10 Apr 2025 18:29:12 +0200
> Christian König wrote:
>
>>> Many UIO users performing DMA from their UIO device need to access the
>>>
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> Nouveau currently relies on the assumption that dma_fences will only
> ever get signaled through nouveau_fence_signal(), which takes care of
> removing a signaled fence from the list nouveau_fence_chan.pending.
>
> This self-imposed rule is violated i
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
Am 09.04.25 um 04:39 schrieb Linus Torvalds:
> On Tue, 8 Apr 2025 at 09:07, Fedor Pchelkin wrote:
>>> Linus comment is about kvmalloc(), but the code here is using
>>> kvmalloc_array() which as far as I know is explicitly made to safely
>>> allocate arrays with parameters provided by userspace.
>
Am 08.04.25 um 11:17 schrieb Denis Arefev:
> The user can set any value to the variable ‘bo_number’, via the ioctl
> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect the arithmetic
> expression ‘in->bo_number * in->bo_info_size’, which is prone to
> overflow. Add a valid value check.
As far as I
Otherwise triggering sysfs multiple times without other submissions in
between only runs the shader once.
v2: add some comment
v3: re-add missing cast
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions
Am 10.04.25 um 19:20 schrieb Boris Brezillon:
> [SNIP]
Faulting is only legal when you have something like HMM, SVM or
whatever you call it. And then you can just use a plain shmem
object to provide you with backing pages.
I mean we could in theory allow faulting on GEM obj
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> nouveau_fence_done() contains an if-branch which checks for the
> existence of either of two fence backend ops. Those two are the only
> backend ops existing in Nouveau, however; and at least one backend ops
> must be in use for the entire driver to b
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> Nouveau currently relies on the assumption that dma_fences will only
> ever get signaled through nouveau_fence_signal(), which takes care of
> removing a signaled fence from the list nouveau_fence_chan.pending.
>
> This self-imposed rule is violated i
Hi Boris,
Am 10.04.25 um 17:53 schrieb Boris Brezillon:
> Hi Christian,
>
> On Thu, 10 Apr 2025 17:05:07 +0200
> Christian König wrote:
>
>> Hi Boris,
>>
>> thanks for looping me in. Can you also send the full patch set to me since I
>> don't see th
Am 10.04.25 um 16:53 schrieb Bastien Curutchet:
> Hi all,
>
> Many UIO users performing DMA from their UIO device need to access the
> DMA addresses of the allocated buffers. There are out-of-tree drivers
> that allow to do it but nothing in the mainline.
Well that basically disqualifies this patc
Am 09.04.25 um 19:27 schrieb Linus Torvalds:
> On Wed, 9 Apr 2025 at 00:29, Christian König wrote:
>> I mean open coding the limit checks everywhere certainly works, but as far
>> as I can see it would be more defensive if we do that inside
>> kvmalloc_array().
> No.
>
Hi Boris,
thanks for looping me in. Can you also send the full patch set to me since I
don't see that on the mailing list (yet maybe).
Am 10.04.25 um 16:48 schrieb Boris Brezillon:
> +Christian, Alyssa and Faith, as suggested by Sima. I'll make sure to
> Cc you on v4, but before that, I'd like t
Am 10.04.25 um 15:56 schrieb Qiang Yu:
> On Thu, Apr 10, 2025 at 8:35 PM Christian König
> wrote:
>> Am 10.04.25 um 11:33 schrieb Qiang Yu:
>>> On Tue, Apr 8, 2025 at 11:48 PM Erico Nunes wrote:
>>>> With this callback implemented, a terminating application will
Am 10.04.25 um 05:52 schrieb SRINIVASAN SHANMUGAM:
>
> On 4/9/2025 7:16 PM, SRINIVASAN SHANMUGAM wrote:
>>
>> On 4/9/2025 7:11 PM, SRINIVASAN SHANMUGAM wrote:
>>>
>>> On 4/9/2025 6:45 PM, SRINIVASAN SHANMUGAM wrote:
>>>>
>>>> On 4/9/20
Am 10.04.25 um 15:09 schrieb Philipp Stanner:
> On Thu, 2025-04-10 at 14:58 +0200, Christian König wrote:
>> Am 10.04.25 um 11:24 schrieb Philipp Stanner:
>>> Nouveau currently relies on the assumption that dma_fences will
>>> only
>>> ever get signaled through
Am 10.04.25 um 15:09 schrieb Philipp Stanner:
> On Thu, 2025-04-10 at 14:58 +0200, Christian König wrote:
>> Am 10.04.25 um 11:24 schrieb Philipp Stanner:
>>> Nouveau currently relies on the assumption that dma_fences will
>>> only
>>> ever get signaled through
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> Nouveau currently relies on the assumption that dma_fences will only
> ever get signaled through nouveau_fence_signal(), which takes care of
> removing a signaled fence from the list nouveau_fence_chan.pending.
>
> This self-imposed rule is violated i
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> nouveau_fence_done() contains an if-branch which checks for the
> existence of either of two fence backend ops. Those two are the only
> backend ops existing in Nouveau, however; and at least one backend ops
> must be in use for the entire driver to b
Am 10.04.25 um 14:21 schrieb Danilo Krummrich:
> On Thu, Apr 10, 2025 at 02:13:34PM +0200, Christian König wrote:
>> Am 10.04.25 um 11:24 schrieb Philipp Stanner:
>>> Nouveau currently relies on the assumption that dma_fences will only
>>> ever get signaled through no
Am 10.04.25 um 14:21 schrieb Danilo Krummrich:
> On Thu, Apr 10, 2025 at 02:13:34PM +0200, Christian König wrote:
>> Am 10.04.25 um 11:24 schrieb Philipp Stanner:
>>> Nouveau currently relies on the assumption that dma_fences will only
>>> ever get signaled through no
Am 10.04.25 um 11:33 schrieb Qiang Yu:
> On Tue, Apr 8, 2025 at 11:48 PM Erico Nunes wrote:
>> With this callback implemented, a terminating application will wait for
>> the sched entity to be flushed out to the hardware and cancel all other
>> pending jobs before destroying its context.
> We do f
Am 10.04.25 um 11:51 schrieb Philipp Stanner:
> On Thu, 2025-04-10 at 11:24 +0200, Philipp Stanner wrote:
>> Contains two patches improving nouveau_fence_done(), and one
>> addressing
>> an actual bug (race):
> Oops, that's the wrong calltrace. Here we go:
>
> [ 85.791794] Call Trace: [ 85.791796]
Am 10.04.25 um 11:51 schrieb Philipp Stanner:
> On Thu, 2025-04-10 at 11:24 +0200, Philipp Stanner wrote:
>> Contains two patches improving nouveau_fence_done(), and one
>> addressing
>> an actual bug (race):
> Oops, that's the wrong calltrace. Here we go:
>
> [ 85.791794] Call Trace: [ 85.791796]
Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> Nouveau currently relies on the assumption that dma_fences will only
> ever get signaled through nouveau_fence_signal(), which takes care of
> removing a signaled fence from the list nouveau_fence_chan.pending.
>
> This self-imposed rule is violated i
Am 09.04.25 um 19:27 schrieb Linus Torvalds:
> On Wed, 9 Apr 2025 at 00:29, Christian König wrote:
>> I mean open coding the limit checks everywhere certainly works, but as far
>> as I can see it would be more defensive if we do that inside
>> kvmalloc_array().
> No.
>
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 15:18 schrieb Ce Sun:
> Checking hive is more readable.
>
> The following smatch warning:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6820 amdgpu_pci_slot_reset()
> warn: iterator used outside loop: 'tmp_adev'
Please also remove the setting of hive and tmp_adev to NULL at the decla
ee to
add Reviewed-by: Christian König .
But I would at least give Alex a chance to take a loop and double check.
Regards,
Christian.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/am
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
dgpu: Multi-GPU DPC recovery support")
I think we should drop that. While the existing code didn't looked nice it
would actually work as far as I can see.
> Reported-by: Dan Carpenter
> Signed-off-by: Ce Sun
Apart from that Reviewed-by: Christian König .
Regards,
Christian
>
Am 09.04.25 um 12:28 schrieb Philipp Stanner:
> On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
>> Sometimes drivers need to be able to submit multiple jobs which
>> depend on
>> each other to different schedulers at the same time, but using
>> drm_sched_job_
Am 09.04.25 um 12:28 schrieb Philipp Stanner:
> On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
>> Sometimes drivers need to be able to submit multiple jobs which
>> depend on
>> each other to different schedulers at the same time, but using
>> drm_sched_job_
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
fix the logic
Signed-off-by: Christian König
Reviewed-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 94 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5 +-
3 files changed, 39 insertions(+), 66
Am 09.04.25 um 04:39 schrieb Linus Torvalds:
> On Tue, 8 Apr 2025 at 09:07, Fedor Pchelkin wrote:
>>> Linus comment is about kvmalloc(), but the code here is using
>>> kvmalloc_array() which as far as I know is explicitly made to safely
>>> allocate arrays with parameters provided by userspace.
>
ontexts from running into a
> race condition between running tasks and context destroy when
> terminating.
>
> Signed-off-by: Erico Nunes
Looks perfectly valid to me and is most likely the right thing to do for other
drivers as well.
Reviewed-by: Christian König
> ---
> driver
: Christian König
Reviewed-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 96 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5 +-
3 files changed, 40 insertions(+), 67 deletions(-)
diff --git a/drivers
Am 08.04.25 um 14:41 schrieb Sunil Khatri:
> Add the pid and the process name of the process
> with the userq manager which could be used in
> debugging and understanding error messages better.
That should be unnecessary.
We already have that in the DRM file as well as the VM which is also update
Am 08.04.25 um 13:54 schrieb Fedor Pchelkin:
> If user can request an arbitrary size value then we should use __GFP_NOWARN
> and back on the allocator to return NULL in case it doesn't even try to
> satisfy an enormous memory allocation request (in which case it yells in
> the log without __GFP_NOW
Am 08.04.25 um 13:54 schrieb Fedor Pchelkin:
> If user can request an arbitrary size value then we should use __GFP_NOWARN
> and back on the allocator to return NULL in case it doesn't even try to
> satisfy an enormous memory allocation request (in which case it yells in
> the log without __GFP_NOW
Am 08.04.25 um 11:39 schrieb Fedor Pchelkin:
> On Tue, 08. Apr 11:26, Christian König wrote:
>> Am 08.04.25 um 11:17 schrieb Denis Arefev:
>>> The user can set any value to the variable ‘bo_number’, via the ioctl
>>> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect th
Am 08.04.25 um 11:39 schrieb Fedor Pchelkin:
> On Tue, 08. Apr 11:26, Christian König wrote:
>> Am 08.04.25 um 11:17 schrieb Denis Arefev:
>>> The user can set any value to the variable ‘bo_number’, via the ioctl
>>> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect th
Am 08.04.25 um 11:17 schrieb Denis Arefev:
> The user can set any value to the variable ‘bo_number’, via the ioctl
> command DRM_IOCTL_AMDGPU_BO_LIST. This will affect the arithmetic
> expression ‘in->bo_number * in->bo_info_size’, which is prone to
> overflow. Add a valid value check.
As far as I
Am 05.04.25 um 03:57 schrieb T.J. Mercier:
> On Fri, Apr 4, 2025 at 1:47 AM Christian König
> wrote:
>> Hi Maxime,
>>
>> Am 03.04.25 um 17:47 schrieb Maxime Ripard:
>>> On Thu, Apr 03, 2025 at 09:39:52AM +0200, Christian König wrote:
>>>>> For the
Am 07.04.25 um 18:29 schrieb Maxime Ripard:
> The system heap is storing its struct dma_heap pointer in a global
> variable but isn't using it anywhere.
>
> Let's move the global variable into system_heap_create() to make it
> local.
>
> Signed-off-by: Maxime Ripard
Am 07.04.25 um 16:44 schrieb Matthew Auld:
> On 07/04/2025 15:32, Christian König wrote:
>> Am 07.04.25 um 16:18 schrieb Matthew Auld:
>>> The page_link lower bits of the first sg could contain something like
>>> SG_END, if we are mapping a single VRAM page or contiguo
if we mapped struct pages vs VRAM.
>
> Fixes: f44ffd677fb3 ("drm/amdgpu: add support for exporting VRAM using
> DMA-buf v3")
> Signed-off-by: Matthew Auld
> Cc: Christian König
> Cc: amd-gfx@lists.freedesktop.org
> Cc: # v5.8+
Good point, haven't thought about
Am 05.04.25 um 09:32 schrieb SRINIVASAN SHANMUGAM:
>
> On 4/4/2025 7:46 PM, Christian König wrote:
>> This reverts commit c2cc3648ba517a6c270500b5447d5a1efdad5936. Turned out
>> that this has some negative consequences for some workloads. Instead check
>> if the cleaner sh
Am 03.04.25 um 12:25 schrieb Danilo Krummrich:
> On Thu, Apr 03, 2025 at 12:17:29PM +0200, Philipp Stanner wrote:
>> On Thu, 2025-04-03 at 12:13 +0200, Philipp Stanner wrote:
>>> -static int
>>> -nouveau_fence_signal(struct nouveau_fence *fence)
>>> +static void
>>> +nouveau_fence_cleanup_cb(struct
Am 21.03.25 um 17:41 schrieb Xiaogang.Chen:
> From: Xiaogang Chen
>
> by casting size_limit_mb to u64 when calculate pglimit.
>
> Signed-off-by: Xiaogang Chen
Reviewed-by: Christian König
If nobody objects I'm going to push that to drm-misc-fixes.
Regards,
Christian.
the object.
> Add lockdep assertions to help validate this.
>
> Signed-off-by: Asahi Lina
> Signed-off-by: Daniel Almeida
Oh, yeah that is certainly a good idea.
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 4
> 1 file changed, 4
ce is also dropped
on error.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 57 +++---
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 5cc5f59
Am 24.03.25 um 12:23 schrieb Bert Karwatzki:
> Am Sonntag, dem 23.03.2025 um 17:51 +1100 schrieb Balbir Singh:
>> On 3/22/25 23:23, Bert Karwatzki wrote:
>>> ...
>>> So why is use_dma32 enabled with nokaslr? Some more printk()s give this
>>> result:
>>>
>>> The GPUs:
>>> built-in:
>>> 08:00.0 VGA
This looks unnecessary and actually extremely harmful since using kmap()
is not possible while inside the ring reset.
Remove all the extra mapping and unmapping of the MQDs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 88 +++-
drivers/gpu/drm
Hi guys,
as partially discussed on the list already amdgpu has a bug in it's gang
submission code.
Basic problem is to add the correct dependency to the gang leader we
need to arm the other gang members first, but that is a point of no
return and it is possible that adding the dependencies fails
too.
>
> And I should probably test round-robin at some point, to see if we are maybe
> okay to drop unconditionally, it or further work improving qddl would be
> needed.
>
> v2:
> * Fixed many rebase errors.
> * Added some new patches.
> * Dropped single shot dependec
1 - 100 of 1884 matches
Mail list logo
