On Wed, 10 Apr 2019 12:24:24 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-04-10 11:09:47) > > On Wed, 10 Apr 2019 10:17:33 +0200, > > Chris Wilson wrote: > > > > > > While we only allow a single display power reference, the current > > > acquisition/release is racy and a direct call may run concurrently with > > > a runtime-pm worker. Prevent the double unreference by atomically > > > tracking the display_power_active cookie. > > > > > > Testcase: igt/i915_pm_rpm/module-reload #glk-dsi > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > Cc: Takashi Iwai <tiwai@xxxxxxx> > > > Cc: Imre Deak <imre.deak@xxxxxxxxx> > > > > I rather prefer a more straightforward conversion, e.g. something like > > below. Checking the returned cookie as the state flag is not quite > > intuitive, so revive the boolean state flag, and handle it > > atomically. > > Access to the cookie itself is not atomic there, and theoretically > there could be a get/put/get running concurrently. Are you sure don't > want a refcount and lock here? :) The refcount is what we want to reduce, so the suitable option would be a (yet another) mutex although the cmpxchg() should be enough for normal cases. > Your call. For the case CI is hitting, it should do the trick (as we are > only seeing the race on put/put I think). CI will answer in a hour or > two. OK, once when it seems working, I'll respin a patch with a mutex instead. We have already a one that is used for the link state change, and this can be reused. thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
