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]

Date:	Mon, 14 Jun 2010 09:44: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: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


--
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/