linux-kernel - Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

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: <20080106231848.762e93c1.akpm@linux-foundation.org>
Date:	Sun, 6 Jan 2008 23:18:48 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mark Lord <lkml@....ca>
Cc:	Venki Pallipadi <venkatesh.pallipadi@...el.com>,
	Arjan van de Ven <arjan@...radead.org>, abelay@...ell.com,
	lenb@...nel.org, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	rjw@...k.pl
Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord <lkml@....ca> wrote:

> Venki Pallipadi wrote:
> > Reintroduce run time configurable max_cstate for !CPU_IDLE case.
> > 
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
> > 
> > Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > ===================================================================
> > --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c
> > +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
> >  #define PM_TIMER_TICKS_TO_US(p)		(((p) * 1000)/(PM_TIMER_FREQUENCY/1000))
> >  
> >  static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
> > +#ifdef CONFIG_CPU_IDLE
> >  module_param(max_cstate, uint, 0000);
> > +#else
> > +module_param(max_cstate, uint, 0644);
> > +#endif
> >  static unsigned int nocst __read_mostly;
> >  module_param(nocst, uint, 0000);
> >  
> ..
> 
> Can we get this patch upstream so that a stock 2.6.24 will work here?
> 

umm, OK, I queued it for 2.6.24.  I'll give people a day or so to comment
on this.

I had to invent some silly changlelog for it.  Please review it for
accuracy and completeness?

It isn't complete, really.  How come we only make max_cstate writeable if
CONFIG_CPU_IDLE=n?  What happens to people who were reliant upon writeable
max_cstate who now enable CPU_IDLE?  Things still break?  What is the
rationale behind this?  What constraints led us to this decision?




From: Venki Pallipadi <venkatesh.pallipadi@...el.com>

This was writeable in 2.6.23 but the cpuidle merge made it read-only.  But
some people's scripts (ie: Mark's) were writing to it.

As an unhappy compromise, make max_cstate writeable again if the kernel was
configured without CONFIG_CPU_IDLE.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
Cc: Mark Lord <lkml@....ca>
Cc: Arjan van de Ven <arjan@...radead.org>
Cc: Len Brown <lenb@...nel.org>
Cc: Ingo Molnar <mingo@...e.hu>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 drivers/acpi/processor_idle.c |    4 ++++
 1 file changed, 4 insertions(+)

diff -puN drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case
+++ a/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)		(((p) * 1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, 0000);
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, 0000);
 
_

--
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/