linux-kernel - Re: [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: <20100609193132.2ac313b0@schatten.dmk.lab>
Date:	Wed, 9 Jun 2010 19:31:32 +0200
From:	Florian Mickler <florian@...kler.org>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	markgross@...gnar.org, mgross@...ux.intel.com,
	linville@...driver.com, Frederic Weisbecker <fweisbec@...il.com>,
	Jonathan Corbet <corbet@....net>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] pm_qos: make update_request non blocking

On Wed, 09 Jun 2010 13:05:49 -0400
James Bottomley <James.Bottomley@...e.de> wrote:

> On Wed, 2010-06-09 at 18:32 +0200, Florian Mickler wrote:
> > Yeah, but for blocking notification it is not that bad. 
> 
> The network latency notifier uses the value to recalculate something.
> Losing the last value will mean it's using stale data.

Ah. Indeed. I didn't do my homework there. That sucks. (Btw, I know why
you said "recalculate _something_" :) )

It even fetches via pm_qos_get_request() in the middle. But obviously
if we do not report the last value but the value before that, then this
is bloed. 

We could fix it though for all current (two) in tree users by passing
always a negative value in to the notification. Then the network
notifier fetches the value via pm_qos_get_request(); 
And cpuidle ignores the value anyways. 

> > 
> > pm_qos was the second kind of operation up until now, because the
> > notifiers may have got scheduled away while blocked. 
> 
> Actually, no ... the current API preserves ordering semantics.  If a
> notifier sleeps and another change comes along, the update callsite will
> sleep on the notifier's mutex ... so ordering is always preserved.

Ah! Ordering. Something I didn't thought of. But still no luck for me. 

> 
> > I think we should allow for both kinds of operations simultaneous. But
> > as I got that pushback to the change from John Linville as I touched his
> > code, I got a bit reluctant and just have done the simple variant. :)
> 
> The code I proposed does ... but it relies on the callsite supplying the
> necessary context.
> 

Yes, I know. It's just that if we want to have both kind's of notifiers
we need to use a atomic_notifier chain for that constraint. And then we
have the issue that John objected to, namely pushing all the
schedule_work code to each of the API-Users. 

Anyway, I think your patch is better in that it is correct.

It just doesn't solve the issue for constraints where drivers want to
update from interrupt but notifiers want to be able to work from
process context. 

> James
> 

Cheers,
Flo
--
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/