linux-kernel - Re: [linux-pm] [PATCH v4] pm_qos: make update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1276528206.5374.24.camel@mulgrave.site>
Date:	Mon, 14 Jun 2010 10:10:06 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Florian Mickler <florian@...kler.org>
Cc:	Jonathan Corbet <corbet@....net>,
	Frederic Weisbecker <fweisbec@...il.com>,
	markgross@...gnar.org, linville@...driver.com,
	linux-kernel@...r.kernel.org,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [linux-pm] [PATCH v4] pm_qos: make update_request non blocking

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@...e.de> 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@...e.de> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/