On Mon, 2010-06-14 at 16:49 +0200, Florian Mickler wrote: > On Mon, 14 Jun 2010 09:44:06 -0500 > James Bottomley <James.Bottomley@xxxxxxx> wrote: > > > On Mon, 2010-06-14 at 16:33 +0200, Florian Mickler wrote: > > > On Fri, 11 Jun 2010 09:25:52 -0500 > > > James Bottomley <James.Bottomley@xxxxxxx> wrote: > > > > > > > > > > > Actually, pm_qos_remove now needs a flush_scheduled work since you don't > > > > want to return until the list is clear (since the next action may be to > > > > free the object). > > > > > > The work-items are allocated in the pm_qos objects (which get never > > > freed), so we should be fine there. > > > > That's not a safe assumption. Once we get into drivers, timers and cpu > > ilde states, I can see these things being in modules. > > > > Regardless, it's bad programming practise to be using something after > > the final remove is called, it certainly violates the principle of least > > surprise and would usually eventually cause problems. > > > > James > > > > I absolutely defer to you in this question. But there is no > pm_qos_remove at the moment, as far as I see? Should I add one? When > and how would it be called? > > Maybe I'm not understanding you right at the moment. You need to flush in pm_qos_remove_notifier() to make sure you aren't racing deferred work in the removed notifier with a return from remove, so that the outcome is always consistent (i.e. the notifier sees all pending events before removal). On closer inspection, it looks like the notifier mutexes are sufficient to make sure it doesn't return running the notifier to be removed ... but that does mean that add and remove require user context. James _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
