linux-kernel - Re: [RFC][PATCH] cpufreq: Do not hold driver module references for additional policy CPUs

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: <CAKohpokdZ=JE8riYxJd+abfaDo6RfqnOjNpbFkb+ph_E-O6L_A@mail.gmail.com>
Date:	Thu, 1 Aug 2013 22:54:08 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, cpufreq@...r.kernel.org,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC][PATCH] cpufreq: Do not hold driver module references for
 additional policy CPUs

On 1 August 2013 20:54, Srivatsa S. Bhat
<srivatsa.bhat@...ux.vnet.ibm.com> wrote:
> Well, I now agree that we don't have to keep the module refcount
> non-zero as long as CPUs are being managed (that was just my
> misunderstanding, sorry for the noise). However, I think the _get()
> and _put() used in the existing code is for synchronization: that
> is, to avoid races between trying to unload the cpufreq driver
> module and running a hotplug notifier (and calling the driver module's
> ->init() or ->exit() function).
>
> With that being the case, I think we can retain the module refcounts
> and use them only for synchronization. And naturally the refcount
> should drop to zero after the critical section; no point keeping
> it incremented until the CPU is taken offline.
>
> Or, am I confused again?

No, you aren't.

But, for synchronization we need some blocking stuff, so that when
user tries to rmmod the module, it should wait until other critical
sections are over and then unload the module. But here, we are
simply returning from rmmod, saying that we are busy :)

So, for that kind of synchronization we better use locks available
inside cpufreq core of if required another variable which can be
used for refcount. But now this.
--
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/