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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 10 Oct 2008 12:03:50 -0700
From:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	Ingo Molnar <mingo@...e.hu>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: apic - unify APIC_DIVISOR

On Fri, Oct 10, 2008 at 10:16:45AM -0700, Cyrill Gorcunov wrote:
> [Pallipadi, Venkatesh - Fri, Oct 10, 2008 at 10:07:38AM -0700]
> |
> |
> | >-----Original Message-----
> | >From: Cyrill Gorcunov [mailto:gorcunov@...il.com]
> | >Sent: Friday, October 10, 2008 9:31 AM
> | >To: Pallipadi, Venkatesh
> | >Cc: Ingo Molnar; Maciej W. Rozycki; LKML
> | >Subject: Re: [PATCH] x86: apic - unify APIC_DIVISOR
> | >
> | >[Pallipadi, Venkatesh - Fri, Oct 10, 2008 at 09:11:06AM -0700]
> | >|
> | >|
> | >| Agree with the APIC_DIVISOR part.
> | >|
> | >| But, not sure why/how the second change is related to this
> | >APIC_DIVISOR being 16.
> | >| Also, another nit. Technically we are not setting the "APIC
> | >counter to maximum"
> | >| as we do divide by 16 before programming initial count
> | >register in __setup_APIC_LVTT().
> | >|
> | >| Thanks,
> | >| Venki
> | >|
> | >
> | >From __setup_APIC_LVTT(0xffffffff, 0, 0) caller point of view we do
> | >set maximum possible value. How you could make it bigger?
> | >(without additional changes _inside_ __setup_APIC_LVTT itself).
> |
> |
> | The basic question is why are we making this change now? Is the old value
> | breaking some system today? Or Is it not to break some future system with
> | very high bus clock freq? If we are doing it to future proof things,
> | we should be making more changes inside __setup_APIC_LVTT and make
> | this maximum possible value..
> |
> | >Actually I wouldn't mind if you fix the comment if you don't like
> | >this 'correlation' btw CLKs divisor and APIC_DIVISOR. No problem :)
> |
> | No problem. I can send a separate patch to change this calibration
> | count to maximum once I understand why exactly we are doing it now :).
> |
> | Thanks,
> | Venki
> |
> 
> We do unify apic code I would say.
> 

If there is no pressing reason to change the initial calibration value, how
about the simple patch below.

The 10^9 value that is used for 100 mS calibration time is pretty big as
tglx's comment points out. We will only underflow it if there is a
bus clock running at 10 GHz * 16 = 160 Ghz.

This way we will not fix something that is not really broken today and will not
break in foreseeable future.

Thanks,
Venki




From: Cyrill Gorcunov <gorcunov@...il.com>
Author: Cyrill Gorcunov <gorcunov@...il.com>

x86: apic - unify APIC_DIVISOR

Use APIC_DIVISOR being set to 16 for both 32/64bit
mode.

Also typo error (CONFG instead of proper CONFIG) fixed.
The error was caught by Venkatesh Pallipadi, thanks a lot Venkatesh!

See details on http://lkml.org/lkml/2008/10/9/425

Reported-by: Venkatesh Pallipad <venkatesh.pallipadi@...el.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@...il.com>
Acked-by: "Maciej W. Rozycki" <macro@...ux-mips.org>
Acked-by: Venkatesh Pallipadi <Venkatesh Pallipadi@...el.com>
Signed-off-by: Ingo Molnar <mingo@...e.hu>

diff --git a/arch/x86/kernel/apic.c b/arch/x86/kernel/apic.c
--- a/arch/x86/kernel/apic.c
+++ b/arch/x86/kernel/apic.c
@@ -332,11 +332,7 @@ int lapic_get_maxlvt(void)
  */
 
 /* Clock divisor */
-#ifdef CONFG_X86_64
-#define APIC_DIVISOR 1
-#else
 #define APIC_DIVISOR 16
-#endif
 
 /*
  * This function sets up the local APIC timer, with a timeout of
--
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