From: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
To: "VURDIGERENATARAJ, CHANDAN" <CHANDAN.VURDIGERENATARAJ@amd.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "Chen, JingWen \(Wayne\)" <JingWen.Chen2@amd.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>,
"Liu, Monk" <Monk.Liu@amd.com>,
"Yao, Yiqing\(James\)" <YiQing.Yao@amd.com>
Subject: Re: [PATCH 3/5] drm/amdgpu: Prevent race between late signaled fences and GPU reset.
Date: Tue, 21 Jun 2022 22:41:07 -0400 [thread overview]
Message-ID: <354c3f15-1ace-db03-591e-00b70176ec2f@amd.com> (raw)
In-Reply-To: <MW4PR12MB56688CDB45612B014D92BA4796B29@MW4PR12MB5668.namprd12.prod.outlook.com>
You have a job in the pending list which is marked as not finished in
drm_sched_stop
(https://elixir.bootlin.com/linux/v5.16/source/drivers/gpu/drm/scheduler/sched_main.c#L420),
s_fence signal cb removed and the job is kept in pending list.
Later you will try to manually clear the HW fence of this job in here
(https://elixir.bootlin.com/linux/v5.16/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L4492)
but the EOP interrupt can fire for that fence exactly at this
moment and you have concurrent access to fence driver's fence array
from both amdgpu_process_fence and amdgpu_fence_driver_clear_job_fences
which is not supposed to happen.Yiqing reported to me a race during
debugging
we did of the original refcount bug and it looked to me like this
scenario. Seems to me the EOP ISR handler should be prevented from
running during this time at least.
Andrey
On 2022-06-21 21:47, VURDIGERENATARAJ, CHANDAN wrote:
> Hi,
>
> Is this a preventive fix or you found errors/oops/hangs?
> If you had found errors/oops/hangs, can you please share the details?
>
> BR,
> Chandan V N
>
>
>> On 2022-06-21 03:25, Christian König wrote:
>>> Am 21.06.22 um 00:03 schrieb Andrey Grodzovsky:
>>>> Problem:
>>>> After we start handling timed out jobs we assume there fences won't
>>>> be signaled but we cannot be sure and sometimes they fire late. We
>>>> need to prevent concurrent accesses to fence array from
>>>> amdgpu_fence_driver_clear_job_fences during GPU reset and
>>>> amdgpu_fence_process from a late EOP interrupt.
>>>>
>>>> Fix:
>>>> Before accessing fence array in GPU disable EOP interrupt and flush
>>>> all pending interrupt handlers for amdgpu device's interrupt line.
>>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++++
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 26
>>>> ++++++++++++++++++++++
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
>>>> 3 files changed, 31 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> index 2b92281dd0c1..c99541685804 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>>> @@ -4605,6 +4605,8 @@ int amdgpu_device_pre_asic_reset(struct
>>>> amdgpu_device *adev,
>>>> amdgpu_virt_fini_data_exchange(adev);
>>>> }
>>>> + amdgpu_fence_driver_isr_toggle(adev, true);
>>>> +
>>>> /* block all schedulers and reset given job's ring */
>>>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>>>> struct amdgpu_ring *ring = adev->rings[i]; @@ -4620,6
>>>> +4622,8 @@ int amdgpu_device_pre_asic_reset(struct
>>>> amdgpu_device *adev,
>>>> amdgpu_fence_driver_force_completion(ring);
>>>> }
>>>> + amdgpu_fence_driver_isr_toggle(adev, false);
>>>> +
>>>> if (job && job->vm)
>>>> drm_sched_increase_karma(&job->base);
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>>>> index a9ae3beaa1d3..d6d54ba4c185 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>>>> @@ -532,6 +532,32 @@ void amdgpu_fence_driver_hw_fini(struct
>>>> amdgpu_device *adev)
>>>> }
>>>> }
>>>> +void amdgpu_fence_driver_isr_toggle(struct amdgpu_device *adev,
>>>> bool stop)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
>>>> + struct amdgpu_ring *ring = adev->rings[i];
>>>> +
>>>> + if (!ring || !ring->fence_drv.initialized ||
>>>> !ring->fence_drv.irq_src)
>>>> + continue;
>>>> +
>>>> + if (stop)
>>>> + amdgpu_irq_put(adev, ring->fence_drv.irq_src,
>>>> + ring->fence_drv.irq_type);
>>>> + else
>>>> + amdgpu_irq_get(adev, ring->fence_drv.irq_src,
>>>> + ring->fence_drv.irq_type);
>>> That won't work like this. This increments/decrements the reference
>>> count for the IRQ, but doesn't guarantee in any way that they are
>>> stopped/started.
>>
>> I understand that, i just assumed that the fence driver is the only holder of this interrupt source (e.g. regCP_INT_CNTL_RING0) ?
>> I can disable amdgpu interrupt line totally using disable_irq - would this be better ?
>>
>>
>>>
>>>> + }
>>>> +
>>>> + /* TODO Only waits for irq handlers on other CPUs, maybe
>>>> local_irq_save
>>>> + * local_irq_local_irq_restore are needed here for local
>>>> interrupts ?
>>>> + *
>>>> + */
>>> Well that comment made me smile. Think for a moment what the local CPU
>>> would be doing if an interrupt would run :)
>>
>> No, I understand this of course, I am ok to be interrupted by interrupt handler at this point, what i am trying to do is to prevent amdgpu_fence_process to run concurrently with amdgpu_fence_driver_clear_job_fences - that is what this function is trying to prevent - i disable and >flush pending EOP ISR handlers before the call to clear fences and re-enable after.
>> I guess we can also introduce a spinlock to serialize them ? Yiqing reported seeing a race between them so we have to do something.
>>
>> Andrey
>>
>>
>>> Cheers,
>>> Christian.
>>>
>>>> + if (stop)
>>>> + synchronize_irq(adev->irq.irq); }
>>>> +
>>>> void amdgpu_fence_driver_sw_fini(struct amdgpu_device *adev)
>>>> {
>>>> unsigned int i, j;
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>>> index 7d89a52091c0..82c178a9033a 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>>> @@ -143,6 +143,7 @@ signed long amdgpu_fence_wait_polling(struct
>>>> amdgpu_ring *ring,
>>>> uint32_t wait_seq,
>>>> signed long timeout);
>>>> unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring);
>>>> +void amdgpu_fence_driver_isr_toggle(struct amdgpu_device *adev, bool
>>>> stop);
>>>> /*
>>>> * Rings.
next prev parent reply other threads:[~2022-06-22 2:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 22:02 [PATCH 0/5] Rework amdgpu HW fence refocunt and update scheduler parent fence refcount Andrey Grodzovsky
2022-06-20 22:02 ` Andrey Grodzovsky
2022-06-20 22:02 ` [PATCH 1/5] drm/amdgpu: Fix possible refcount leak for release of external_hw_fence Andrey Grodzovsky
2022-06-20 22:02 ` Andrey Grodzovsky
2022-06-21 7:19 ` Christian König
2022-06-21 19:34 ` Andrey Grodzovsky
2022-06-22 9:00 ` Christian König
2022-06-22 15:01 ` Andrey Grodzovsky
2022-06-22 15:04 ` Christian König
2022-06-23 21:18 ` Andrey Grodzovsky
2022-06-24 6:00 ` Christian König
2022-06-20 22:02 ` [PATCH 2/5] drm/amdgpu: Add put fence in amdgpu_fence_driver_clear_job_fences Andrey Grodzovsky
2022-06-20 22:02 ` Andrey Grodzovsky
2022-06-21 7:21 ` Christian König
2022-06-20 22:03 ` [PATCH 3/5] drm/amdgpu: Prevent race between late signaled fences and GPU reset Andrey Grodzovsky
2022-06-20 22:03 ` Andrey Grodzovsky
2022-06-21 7:25 ` Christian König
2022-06-21 19:45 ` Andrey Grodzovsky
2022-06-22 1:47 ` VURDIGERENATARAJ, CHANDAN
2022-06-22 2:41 ` Andrey Grodzovsky [this message]
2022-06-22 17:31 ` Andrey Grodzovsky
2022-06-23 5:57 ` Christian König
2022-06-20 22:03 ` [PATCH 4/5] drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer' Andrey Grodzovsky
2022-06-20 22:03 ` Andrey Grodzovsky
2022-06-21 7:26 ` Christian König
2022-06-20 22:03 ` [PATCH 5/5] drm/amdgpu: Follow up change to previous drm scheduler change Andrey Grodzovsky
2022-06-20 22:03 ` Andrey Grodzovsky
2022-06-21 7:28 ` Christian König
2022-06-21 20:00 ` Andrey Grodzovsky
2022-06-22 7:17 ` Christian König
2022-06-22 17:19 ` Andrey Grodzovsky
2022-06-23 5:52 ` Christian König
2022-06-23 14:51 ` Andrey Grodzovsky
2022-06-23 14:54 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=354c3f15-1ace-db03-591e-00b70176ec2f@amd.com \
--to=andrey.grodzovsky@amd.com \
--cc=CHANDAN.VURDIGERENATARAJ@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=JingWen.Chen2@amd.com \
--cc=Monk.Liu@amd.com \
--cc=YiQing.Yao@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.