Re: [PATCH v3 06/14] drm/msm: let the kms drivers clean up a failed kms_init()

[Konrad Dybcio]

On 10/24/26 1:19 AM, Dmitry Baryshkov wrote:
> A failed priv->kms_init() or ->hw_init() is cleaned up by the ->destroy()
> callback, which makes ->destroy() responsible for tearing down a KMS in
> any state between "not initialised at all" and "fully initialised". The
> kernel convention is the opposite: a function which fails undoes its own
> steps, and the teardown only ever sees a fully set up object.
> 
> Let the kms drivers switch to that convention one at a time: skip
> ->destroy() after a failed kms_init() of a driver which sets
> init_unwinds, and let the drivers fold their hardware setup into
> kms_init() and drop ->hw_init(). Set up the mode config before calling
> kms_init(), so that it is already in place for the hardware setup.
> 
> While at it, tear the snapshot worker down after the KMS, in the reverse
> order of its setup. Nothing queues a snapshot until msm_drm_kms_init()
> has succeeded, so no dump can be pending when the KMS goes away.

LLM:

msm_kms_init_vm() arms the IOMMU fault handler inside kms_init, and
that handler queues dump_work, so a fault during init can queue a dump.

The patch then tears down the KMS before the snapshot worker.
kthread_destroy_worker() flushes queued work, so the pending dump would
run against a destroyed KMS. The original order, snapshot first, avoids
that. Unbind (msm_drm_kms_uninit()) keeps the original order, so the two
paths now disagree.

Konrad:

I don't think it's entirely unreasonable to get a iommu error halfway
through init

Konrad