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: <ZoVoUabfZiiAXWKR@alpha.franken.de>
Date: Wed, 3 Jul 2024 17:03:45 +0200
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Huacai Chen <chenhuacai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Serge Semin <fancer.lancer@...il.com>,
	Paul Burton <paulburton@...nel.org>, linux-mips@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/10] MIPS: smp: Manage IPI interrupts as percpu_devid
 interrupts

On Sun, Jun 16, 2024 at 10:03:06PM +0100, Jiaxun Yang wrote:
> IPI interrupts need to be enabled when a new CPU coming up.
> 
> Manage them as percpu_devid interrupts and invoke enable/disable
> functions at appropriate time to perform enabling as required,
> similar to what RISC-V and Arm doing.
> 
> Signed-off-by: Jiaxun Yang <jiaxun.yang@...goat.com>
> ---
>  arch/mips/include/asm/ipi.h | 11 +++++++++++
>  arch/mips/kernel/smp.c      | 26 ++++++++++++++++++++++++--
>  2 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/include/asm/ipi.h b/arch/mips/include/asm/ipi.h
> index df7a0ac4227a..88b507339f51 100644
> --- a/arch/mips/include/asm/ipi.h
> +++ b/arch/mips/include/asm/ipi.h
> @@ -29,6 +29,17 @@ int mips_smp_ipi_allocate(const struct cpumask *mask);
>   * Return 0 on success.
>   */
>  int mips_smp_ipi_free(const struct cpumask *mask);
> +
> +void mips_smp_ipi_enable(void);
> +void mips_smp_ipi_disable(void);
> +#else
> +static inline void mips_smp_ipi_enable(void)
> +{
> +}
> +
> +static inline void mips_smp_ipi_disable(void)
> +{
> +}
>  #endif /* CONFIG_GENERIC_IRQ_IPI */
>  #endif /* CONFIG_SMP */
>  #endif
> diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
> index a6cf6444533e..710644d47106 100644
> --- a/arch/mips/kernel/smp.c
> +++ b/arch/mips/kernel/smp.c
> @@ -186,6 +186,7 @@ irq_handler_t ipi_handlers[IPI_MAX] __read_mostly = {
>  };
>  
>  #ifdef CONFIG_GENERIC_IRQ_IPI
> +static DEFINE_PER_CPU_READ_MOSTLY(int, ipi_dummy_dev);
>  static int ipi_virqs[IPI_MAX] __ro_after_init;
>  static struct irq_desc *ipi_desc[IPI_MAX] __read_mostly;
>  
> @@ -225,13 +226,29 @@ void mips_smp_send_ipi_mask(const struct cpumask *mask,
>  	local_irq_restore(flags);
>  }
>  
> +void mips_smp_ipi_enable(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < IPI_MAX; i++)
> +		enable_percpu_irq(ipi_virqs[i], IRQ_TYPE_NONE);
> +}
> +
> +void mips_smp_ipi_disable(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < IPI_MAX; i++)
> +		disable_percpu_irq(ipi_virqs[i]);
> +}
> +

there is no user of mips_smp_ipi_disable() (at least I didn't see one),
so do we need this patch at all ? Just looking like ARM or RiscV isn't
a justification for code churn.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ