linux-kernel - Re: [PATCH v6 2/8] cpufreq: Add boost frequency support in core

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: <CAKohpokBGyHa=jHYpf358Aaa2kRko9=NtkS_2H_ywAn59h1axQ@mail.gmail.com>
Date:	Fri, 26 Jul 2013 15:03:34 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Lukasz Majewski <l.majewski@...sung.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <eduardo.valentin@...com>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	Lukasz Majewski <l.majewski@...ess.pl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>, durgadoss.r@...el.com,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>
Subject: Re: [PATCH v6 2/8] cpufreq: Add boost frequency support in core

On 26 July 2013 14:03, Lukasz Majewski <l.majewski@...sung.com> wrote:
> On Fri, 26 Jul 2013 12:47:15 +0530 Viresh Kumar wrote,
>> On 25 July 2013 22:03, Lukasz Majewski <l.majewski@...sung.com> wrote:

>> > +int cpufreq_boost_trigger_state(int state)
>> > +{
>> > +       unsigned long flags;
>> > +       int ret = 0;
>> > +
>> > +       if (cpufreq_driver->boost_enabled == state)
>> > +               return 0;
>> > +
>> > +       write_lock_irqsave(&cpufreq_driver_lock, flags);
>> > +       cpufreq_driver->boost_enabled = state;
>> > +       write_unlock_irqrestore(&cpufreq_driver_lock, flags);
>             ^^^^^^^^^^^^^^^^^^^^ [*]
>>
>> Not sure if we should leave the lock at this point of time, as we
>> haven't enabled boost until now.
>
> The problem here is with the cpufreq_driver->set_boost() call.
>
> I tried to avoid acquiring lock at one function and release it at
> another (in this case cpufreq_boost_set_sw), especially since the
> __cpufreq_governor() acquires its own lock - good place for deadlock.
>
> Is it OK for you to grab lock at one function
> (cpufreq_boost_trigger_state()) and then at other function
> (cpufreq_boost_set_sw) release it before calling __cpufreq_governor()
> and grab it again after its completion?

>> > +       ret = cpufreq_driver->set_boost(state);
>> > +       if (ret) {
>> > +               write_lock_irqsave(&cpufreq_driver_lock, flags);
>> > +               cpufreq_driver->boost_enabled = 0;
>>
>> should be:
>>                     cpufreq_driver->boost_enabled = !state;
>
> For me = 0 (or = false) is more readable.
> If you wish, I will change it to = !state.

Its not about readability but logic... What if boost was enabled
earlier and we are disabling it now.. and we reach here.. We
need to enable boost again, whereas you are disabling it.

>> > +int cpufreq_boost_supported(void)
>> > +{
>> > +       if (cpufreq_driver)
>>
>> This routine is always called from places where cpufreq_driver
>> can't be NULL..
>
> It is also called from thermal. And it happens that thermal is
> initialized earlier.
> Then "NULL pointer dereference" happens.

Ok.. Put a likely() around this check for cpufreq_driver..

> In my opinion at [1] we don't need the if (cpufreq_driver) check.
> But it is up to you to decide.

leave it as is.

> If we agree about above comments, I will post v7 ASAP.

Don't post it ASAP, wait for few more days for others to give
comments.. And also I haven't finished reviewing it until
now.
--
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/