Re: [PATCH 0/6] dmaengine: idxd: More error handling fixes

[Jingyi Li <jinli@purestorage.com>]

Hi Vinicius,

We hit the bug fixed by 1/6 and 2/6 in a kdump crash kernel on
systems with DSA: idxd probe fails at device reset ("Device is
HALTED!"), the error path oopses in destroy_workqueue() on a NULL
idxd->wq, and no dump is saved. With slub_debug, the duplicate frees
in idxd_free() are also reported.

Testing: I applied patches 1-3 of this series on top of 6.18.57 and
tested on 10 systems with DSA, triggering kdump with idxd loaded in
the crash kernel, with and without slub_debug=FZPU. Unpatched: 10/10
oopses in destroy_workqueue(), 0/10 dumps saved. With patches 1-3:
10/10 dumps saved in both configurations, no oopses, warnings or
slub reports.

The failure here is at device reset, before idxd_setup_internals(),
so it exercises 1/6 and the idxd_free() part of 2/6; for 3/6 it only
shows no regression on this path.

Could 1-3 carry Cc: stable? The commits named in the Fixes: tags have
been backported to stable kernels (we hit this on 6.18.57). Also,
from reading the code, 1/6 alone only covers the case where idxd->wq
was never allocated: with only 1/6, a failure after
idxd_setup_internals() still destroys the wq twice (once in the
unwind, once in the release callback), which 3/6 fixes by removing
the early destroy. So 1/6 and 3/6 should be backported together.
(Our kdump failure doesn't reach that path, so I haven't reproduced
it.)

For patches 1-3:
Tested-by: Jingyi Li <jinli@purestorage.com>

I sent an overlapping series [2] before finding this one; I've asked
for it to be dropped in favor of this.

[2] https://lore.kernel.org/r/20261028003708.834341-1-jinli@purestorage.com

Thanks,
Jingyi