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: <alpine.LFD.2.02.1110052054040.18778@ionos>
Date:	Wed, 5 Oct 2011 21:13:33 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Fenghua Yu <fenghua.yu@...el.com>
cc:	Ingo Molnar <mingo@...e.hu>, H Peter Anvin <hpa@...or.com>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Tony Luck <tony.luck@...el.com>,
	Asit K Mallick <asit.k.mallick@...el.com>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Len Brown <lenb@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/8] x86, common.c, smpboot.c: Init BSP during BSP online
 and don't offline BSP if irq is bound to it

On Wed, 5 Oct 2011, Fenghua Yu wrote:

> From: Fenghua Yu <fenghua.yu@...el.com>
> 
> During BSP online, enable x2apic and initialize BSP. Don't offline BSP if
> any irq is bound to it.
> 
> Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
> ---
>  arch/x86/include/asm/processor.h |    1 +
>  arch/x86/kernel/cpu/common.c     |   13 ++++++++++---
>  arch/x86/kernel/smpboot.c        |   38 +++++++++++++++++++++++++++++++-------
>  3 files changed, 42 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 0d1171c..d648cae 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -161,6 +161,7 @@ extern struct pt_regs *idle_regs(struct pt_regs *);
>  
>  extern void early_cpu_init(void);
>  extern void identify_boot_cpu(void);
> +extern void identify_boot_cpu_online(void);
>  extern void identify_secondary_cpu(struct cpuinfo_x86 *);
>  extern void print_cpu_info(struct cpuinfo_x86 *);
>  extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 6218439..2ceefb9 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -911,6 +911,14 @@ void __init identify_boot_cpu(void)
>  #endif
>  }
>  
> +void __cpuinit identify_boot_cpu_online(void)
> +{
> +	numa_add_cpu(smp_processor_id());
> +#ifdef CONFIG_X86_32
> +	enable_sep_cpu();
> +#endif

Why this change? This has nothing to do with the changelog. And we
have 3 other call sites for enable_sep_cpu().

> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 9f548cb..cdfa425 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -50,6 +50,7 @@
>  #include <linux/tboot.h>
>  #include <linux/stackprotector.h>
>  #include <linux/gfp.h>
> +#include <linux/kernel_stat.h>

What is this include for?
  
>  #include <asm/acpi.h>
>  #include <asm/desc.h>
> @@ -136,8 +137,8 @@ EXPORT_PER_CPU_SYMBOL(cpu_info);
>  atomic_t init_deasserted;
>  
>  /*
> - * Report back to the Boot Processor.
> - * Running on AP.
> + * Report back to the Boot Processor during boot time or to the caller processor
> + * during CPU online.
>   */
>  static void __cpuinit smp_callin(void)
>  {
> @@ -224,6 +225,13 @@ static void __cpuinit smp_callin(void)
>  	smp_store_cpu_info(cpuid);
>  
>  	/*
> +	 * This function won't run on the BSP during boot time. It run
> +	 * on BSP only when BSP is offlined and onlined again.
> +	 */
> +	if (cpuid == 0)
> +		identify_boot_cpu_online();

Again, what's the point? numa_add_cpu() is called in identify_cpu()
already and you just added that crap here because you failed to fix
smp_store_cpu_info(). That whole patch set is just a sloppy hack which
leaves tons of cpu0 assumptions all over the place instead of cleaning
them up completely.

> +	if (cpu == 0) {
> +		int i;
> +		for (i = 0; i < NR_IRQS; i++) {
> +			struct irq_desc *desc = irq_to_desc(i);
> +
> +			if (!desc)
> +				continue;
> +
> +			if (irqd_irq_disabled(&desc->irq_data))
> +				continue;
> +
> +			if (!irq_can_set_affinity(i)) {
> +				pr_debug("irq%d can't move out of BSP\n", i);
> +				return -EBUSY;
> +			}

This is just disgusting.

Have you ever looked at other code which iterates over the interrupt
descriptors and if yes have you noticed that all that code uses
iterator functions for a fcking good reason? Hint SPARSE_IRQ

What gives you the guarantee that the interrupt is not going to be
enabled right after you offlined the cpu? Do you really think that
chekcing whether the interrupt is disabled is sufficient ????

Is there any guarantee, that an interrupt which is currently not
assigned is going to be requested after you offlined cpu0 ?

We know upfront whether we are using interrupt chips which are not
capable of irq affinity settings. So why the hell do you want to poke
in the interrupt descriptors?

Thanks,

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