Re: CXL related lockdep splats with 6.12-rc4

[Dan Williams <dan.j.williams@intel.com>]

Ira Weiny wrote:
> I was about to get cxl-fixes soaking last night and hit the following
> lockdep splat.[1]
> 
> It is intermittent, occurring about 3 times so far, while running all the
> cxl-tests (nfit and cxl).
> 
> I've been able to hit it with 6.12-rc4 __without__ the cxl fixes patches.
> 
> So I'm thinking it is something in the device handling which has changed
> or missed in rc1 testing.  The intermittent nature (I can't even narrow
> down which cxl-test test fails.  :-/) is making this hard to track.
> 
> It seems to hit during the firmware-update.sh test (which is not even a
> direct cxl test.)  But not always and may depend on a previous test
> causing a lock state to trigger.
> 
> I don't know if this has appeared because of a config change or what
> because I have been testing since rc1.  Config is in [2].
> 
> I've also been able to hit what looks like a similar splat in [3].  But
> I've not seen that reproduce.
> 
> Any ideas on what might be happening would be appreciated.

Going forward do look at using gist.github.com to share dumps.

This is tripping over the online firmware activation unit test in
nfit_test which is strictly an NVDIMM path. The fact that running that
against the full CXL unit test finds this multi-stage lockdep splat is
interesting but also not too surprising.

This is part of the reason I only run:

    meson test -C build --suite cxl

...for CXL work, besides the long running NVDIMM tests that do not add
much value to CXL regression.

Online NVDIMM firmware activation handles this difficult side of effect
of memory going offline in a way that could cause DMA timeouts and other
problems. So the solution attempts to suspend all devices over the
activation event. Given the violence of suspend some deployments choose
to just live with the blip in memory response and hope nothing times
out. So, I would say we should probably document
"test/firmware-update.sh" as a low-value test and hope that CXL never
needs to deal with devices going silent to memory cycles in problematic
ways over firmware activation events.