linux-kernel - Re: [patch] Let smp_call_function

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:	Mon, 14 May 2007 12:11:37 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	randy.dunlap@...cle.com, paulus@...ba.org,
	benh@...nel.crashing.org, David Miller <davem@...emloft.net>,
	Andi Kleen <ak@...e.de>
Subject: Re: [patch] Let smp_call_function_single return -EBUSY.

On Mon, 14 May 2007 11:23:17 +0200
Heiko Carstens <heiko.carstens@...ibm.com> wrote:

> From: Heiko Carstens <heiko.carstens@...ibm.com>
> 
> All architectures that have an implementation of smp_call_function_single
> let it return -EBUSY if it is asked to execute func on the current cpu.
> Therefore the UP version must always return -EBUSY.
> 

smp_call_function_single() is a mess.

- it's unclear to me why smp_call_function_single(cpu, ...) doesn't just
  call the darn function if cpu==smp_processor_id().

- it's unclear to me why smp_call_function_single(cpu, ...) doesn't just
  call the darn function if CONFIG_SMP=n.

- it's unclear to me why smp_call_function_single(cpu, ...) isn't called
  smp_call_function_on(cpu, ...)

- the x86_64 version doesn't return -EBUSY: it returns zero.  Despite its
  claim "Retrurns 0 on success, else a negative status code.".

- i386 _does_ return -EBUSY.

> This of course raises another question: it is not clear in which context
> the smp_call_function* functions are supposed to be called. Should it be
> with preemption disabled or is preemption enabled allowed as well?
> If calling with preemption enabled is allowed then the powerpc implementation
> is broken, since smp_processor_id() as well as num_online_cpus() may change
> while they are accessed.

These are all excellent questions.  And important ones.   I would suggest:

- May be called with preemption enabled.  The implementation must take
  care of that.

- May not be called under local_irq_disable() for the usual reasons.

- Will run the callback function under local_irq_disable() (this is
  unimportant at present, but if we decide to later change it to run the
  callback even on !SMP builds, we'll need to take care of that like we did
  in on_each_cpu())



>  include/linux/smp.h |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6/include/linux/smp.h
> ===================================================================
> --- linux-2.6.orig/include/linux/smp.h
> +++ linux-2.6/include/linux/smp.h
> @@ -99,11 +99,9 @@ static inline void smp_send_reschedule(i
>  #define num_booting_cpus()			1
>  #define smp_prepare_boot_cpu()			do {} while (0)
>  static inline int smp_call_function_single(int cpuid, void (*func) (void *info),
> -				void *info, int retry, int wait)
> +					   void *info, int retry, int wait)
>  {
> -	/* Disable interrupts here? */
> -	func(info);
> -	return 0;
> +	return -EBUSY;
>  }
>  
>  #endif /* !SMP */

Your patch seems appropriate given the present and proposed peculiar
semantics, but I think we need more work in there.  x86_64 needs its return
value fixing asap, surely.


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