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

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Hi,

Jingyi Li <jinli@purestorage.com> writes:

> 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.)
>

I am finishing testing the series, to be sent soon, but added the tags
to direct them to stable, with a small re-ordering of the series (patch
3 is going to be patch 2), hopefully that will make things (slightly)
easier.

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

Thank you for the tests.


Cheers,
-- 
Vinicius