Messages in this thread | | | From | Viresh Kumar <> | Date | Wed, 30 Oct 2019 13:20:56 +0530 | Subject | Re: [PATCH] opp: Reinitialize the list_kref before adding the static OPPs again |
| |
On Mon, 28 Oct 2019 at 17:31, Stephen Boyd <sboyd@kernel.org> wrote: > Quoting Viresh Kumar (2019-10-20 19:25:16)
> Some static OPP is removed at the same time that this function is > called?
Hmm, not just this line but yeah this can be racy in principle though not in practice. As both addition and removal of the static OPPs happen from the same driver, like during cpufreq registration and unregistration.
> Right. I don't understand why the count reaches 0 if we can still get a > pointer to something. I guess we've got this kref thing that has a > lifetime beyond the life of what it's tracking, which is weird.
Something is weird here for sure as the kref is not protecting a specific object here. Maybe we should use a simple counter protected with opp-table lock here.
> Usually > the kref is embedded inside the pointer that is returned by the "get" > call, but here it's outside it and used to track when we should free > static OPPs.
> Why are we removing static OPPs? Shouldn't they just stick > around forever until the device is deleted vs. populated over and over > again?
Because the only use of the static OPPs is gone and so freeing them is the right thing to do. Also, it is possible in principle to change the supported-hw values after removing the cpufreq driver and adding it back, which means it is possible to get a new set of OPPs.
-- viresh
| |