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:	Thu, 01 Aug 2013 20:09:54 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	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 Thursday, August 01, 2013 10:54:08 PM Viresh Kumar wrote:
> 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.

I suppose you wanted to say "But not this"?

I agree.  That said the situation now is that for acpi-cpufreq the module
usage count is 0 (as of linux-next from today), so you can actually rmmod it.

I don't see why it should be different in the case when there are multiple
CPUs for the same policy and hence my patch.  [I don't see the problem with
it as I said to my reply to Srivatsa, so care to explain it to me?.]

Now it seems to me that the code *is* racy (I haven't verified that, though),
so I agree that we should use some other synchronization framework to be able
to rmmod and modprobe cpufreq drivers safely.  Using the driver module usage
counter for that is not quite correct in my view.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ