linux-kernel - Re: [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular

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:	Tue, 5 Apr 2016 14:22:52 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	<rcochran@...utronix.de>
CC:	<linux-kernel@...r.kernel.org>, Len Brown <len.brown@...el.com>,
	Len Brown <lenb@...nel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] drivers/idle: make intel_idle.c driver more explicitly
 non-modular

[Re: [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular] On 05/04/2016 (Tue 05:11) rcochran@...utronix.de wrote:

> On Mon, Apr 04, 2016 at 03:55:35PM -0400, Paul Gortmaker wrote:
> > > This was done in commit 6ce9cd8669fa1195fdc21643370e34523c7ac988
> > > ("intel_idle: disable module support") since "...the module capability
> > > is cauing more trouble than it is worth."
> 
> The reason given in that commit was that "it lost the init race with
> ACPI", whatever that means.
> 
> > > Since this was done over 5y ago, it is safe to say there is no big desire
> > > to overcome the issues with modular versions.  So lets remove the modular
> > > code that is essentially orphaned, so that when reading the driver there
> > > is no doubt it is builtin-only.
> 
> So you want to make the driver non-modular due to lack of desire to
> fix it?
> 
> > This patch will no longer apply since there were several updates to this
> > driver by Richard Cochran dated March 29th.   Before I go and refresh
> > the patch for a v2, is there any objections to the general goal of what
> > the patch was aiming to achieve -- avoiding use of modular infrastructure
> > in non-modular code, and not having module_exit code that can't be run?
> 
> On the one hand, the better way is to fix the issues, keeping the
> driver's modular form.  That way, by loading and unloading, you can
> observe how well it works.  I already started by fixing several bugs
> WRT module init/exit.

So, to be clear, I really don't have a horse in this race.  Be it
built-in or be it modular, I don't care.  But if code pretends to be
modular and is not, and hence has dead code, then I care.  So fixing
this driver to be functionally tristate is just as good as killing
the (currently) unreachable module_exit code IMHO.

It sounds like this discussion will lead us to one of the two, so that
is good.

Paul.
--

> 
> On the other hand, if there is some technical reason why the modular
> form is impossible, then the patch should state it.
> 
> Thanks,
> Richard