All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Philipp Stanner <pstanner@redhat.com>,
	Philipp Reisner <philipp.reisner@linbit.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Simona Vetter <simona@ffwll.ch>,
	Danilo Krummrich <dakr@kernel.org>,
	Philipp Stanner <phasta@kernel.org>
Subject: Re: [PATCH] drm/sched: Fix amdgpu crash upon suspend/resume
Date: Mon, 13 Jan 2025 10:55:08 +0100	[thread overview]
Message-ID: <b055ff59-4653-44d9-a2e0-bb43eb158315@amd.com> (raw)
In-Reply-To: <582e10673bb749f18ebf8a18f46ca573df396576.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

Am 13.01.25 um 09:43 schrieb Philipp Stanner:
> [SNIP]
>>> The handling of NULL values is half-baked.
>>>
>>> In my opinion, you should define if drm_sched_pick_best() may put a
>>> NULL into
>>> rq. If your answer is yes, it might put a NULL there; then, there
>>> should be a
>>> BUG_ON(!entity->rq) after the invocation of
>>> drm_sched_entity_select_rq().
>>> If your answer is no, the BUG_ON() should be in
>>> drm_sched_pick_best().
>> Yeah good point.
>>
>> We might not want a BUG_ON(), that is only justified when we prevent
>> further damage (e.g. random data corruption or similar).
>>
>> I suggest using a WARN(!shed, "Submission without activated
>> sheduler!").
>> This way the system has at least a chance of survival should the
>> scheduler become ready later on.
>>
>> On the other hand the BUG_ON() or the NULL pointer deref should only
>> kill the application thread which is submitting something before the
>> driver is resumed. So that might help to pinpoint where the actually
>> issue is.
> As I see it the BUG_ON() would just be a more pretty NULL pointer
> deref. If we agree that this is effectively a misuse of the scheduler
> API we probably want to add it to make it more pretty, though?

The only alternative I can see is that the scheduler API gracefully 
handles submits to non-ready schedulers. E.g. that 
drm_sched_entity_push_job() detects this condition and instead of 
pushing the job sets and error code and signals the fences.

But that might not be a good idea.

It just moves the crash from one place to another and in general I fully 
agree the driver is misusing the scheduler API to do something which 
won't work and potentially crash the whole system.

> @Philipp:
> BTW, I only just discovered this thread by coincidence. Please use
> get_maintainer. The scheduler currently has 4 maintainers, and none of
> them is on CC.

Oh good, point I was already wondering why nobody else commented and 
didn't realized that nobody was on CC.

Thanks,
Christian.

>
> Danke,
> P.
>
>> Regards,
>> Christian.
>>
>>> That helps guys with zero domain knowledge, like me, to figure out
>>> how
>>> this is all
>>> supposed to work.
>>>
>>> best regards,
>>>    Philipp

[-- Attachment #2: Type: text/html, Size: 3519 bytes --]

  reply	other threads:[~2025-01-13  9:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07 14:02 [PATCH] drm/sched: Fix amdgpu crash upon suspend/resume Philipp Reisner
2025-01-07 14:08 ` Christian König
2025-01-07 15:21   ` Philipp Reisner
2025-01-08  8:19     ` Christian König
2025-01-13  8:43       ` Philipp Stanner
2025-01-13  9:55         ` Christian König [this message]
2025-05-28  9:55           ` Christopher Snowhill
2025-06-02 10:25             ` Philipp Reisner
2025-06-04 10:19               ` Christopher Snowhill
2025-01-08 14:26   ` Alex Deucher
2025-01-08 14:35     ` Christian König
2025-01-10  7:37       ` Philipp Reisner
2025-01-10  8:44         ` Christian König
2025-01-10 14:32           ` Philipp Reisner
2025-01-10 14:47             ` Christian König
2025-01-10 15:10               ` Alex Deucher
2025-01-13  8:32                 ` 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=b055ff59-4653-44d9-a2e0-bb43eb158315@amd.com \
    --to=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phasta@kernel.org \
    --cc=philipp.reisner@linbit.com \
    --cc=pstanner@redhat.com \
    --cc=simona@ffwll.ch \
    /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.