Satyam Sharma wrote:
On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
> Oh wait, the on_one_cpu() patch proposes on UP:
>
> +static inline int on_one_cpu(int cpu, void (*func)(void *info), void
> *info,
> + int retry, int wait)
> +{
>
> /* this needs a if
Satyam Sharma wrote:
On 6/7/07, Avi Kivity [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Oh wait, the on_one_cpu() patch proposes on UP:
+static inline int on_one_cpu(int cpu, void (*func)(void *info), void
*info,
+ int retry, int wait)
+{
/* this needs a if (cpu == 0)
On Thursday 07 June 2007 16:07:04 Satyam Sharma wrote:
> Hi,
>
> I'm about six months late here(!), but I noticed this bug in
> arch/x86_64/kernel/smp.c while preparing another related
> patch today and then found this thread during Googling ...
>
> On 2/9/07, Heiko Carstens <[EMAIL PROTECTED]>
> Indeed -- this was doubly problematic because the un-safeness
> was because of smp_processor_id() as well as the (eventual)
> access of cpu_online_map (via smp_call_function() ->
> num_online_cpus()) ... thanks for letting me know about this.
CPU hotplug is changed to use the freezer anyways.
Indeed -- this was doubly problematic because the un-safeness
was because of smp_processor_id() as well as the (eventual)
access of cpu_online_map (via smp_call_function() -
num_online_cpus()) ... thanks for letting me know about this.
CPU hotplug is changed to use the freezer anyways. It is
On Thursday 07 June 2007 16:07:04 Satyam Sharma wrote:
Hi,
I'm about six months late here(!), but I noticed this bug in
arch/x86_64/kernel/smp.c while preparing another related
patch today and then found this thread during Googling ...
On 2/9/07, Heiko Carstens [EMAIL PROTECTED] wrote:
On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
> Oh wait, the on_one_cpu() patch proposes on UP:
>
> +static inline int on_one_cpu(int cpu, void (*func)(void *info), void
> *info,
> + int retry, int wait)
> +{
>
> /* this needs a if (cpu == 0) check here,
Satyam Sharma wrote:
>
> Oh wait, the on_one_cpu() patch proposes on UP:
>
> +static inline int on_one_cpu(int cpu, void (*func)(void *info), void
> *info,
> + int retry, int wait)
> +{
>
> /* this needs a if (cpu == 0) check here, IMO */
>
> +local_irq_disable();
> +
On 6/7/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
[...]
> Avi Kivity has already a patch which introduces an on_cpu() function which
> looks quite like on_each_cpu(). That way you don't have to open code this
> stuff over and over again:
>
> preempt_disable();
> if (cpu == smp_processor_id())
Hi Heiko,
On 6/7/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
> Replacing the _bh variants and making smp_call_function{_single}
> illegal from all contexts but process is fine for x86_64, as we
> don't really have any driver that needs to use this from softirq
> context in the x86_64 tree.
> >So either all spin_lock_bh's should be converted to spin_lock,
> >which would limit smp_call_function()/smp_call_function_single()
> >to process context & irqs enabled.
> >Or the spin_lock's could be converted to spin_lock_bh which would
> >make it possible to call these two functions even if
Hi,
I'm about six months late here(!), but I noticed this bug in
arch/x86_64/kernel/smp.c while preparing another related
patch today and then found this thread during Googling ...
On 2/9/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
On i386/x86_64 smp_call_function_single() takes call_lock
Hi,
I'm about six months late here(!), but I noticed this bug in
arch/x86_64/kernel/smp.c while preparing another related
patch today and then found this thread during Googling ...
On 2/9/07, Heiko Carstens [EMAIL PROTECTED] wrote:
On i386/x86_64 smp_call_function_single() takes call_lock with
So either all spin_lock_bh's should be converted to spin_lock,
which would limit smp_call_function()/smp_call_function_single()
to process context irqs enabled.
Or the spin_lock's could be converted to spin_lock_bh which would
make it possible to call these two functions even if in softirq
Hi Heiko,
On 6/7/07, Heiko Carstens [EMAIL PROTECTED] wrote:
Replacing the _bh variants and making smp_call_function{_single}
illegal from all contexts but process is fine for x86_64, as we
don't really have any driver that needs to use this from softirq
context in the x86_64 tree. This
On 6/7/07, Heiko Carstens [EMAIL PROTECTED] wrote:
[...]
Avi Kivity has already a patch which introduces an on_cpu() function which
looks quite like on_each_cpu(). That way you don't have to open code this
stuff over and over again:
preempt_disable();
if (cpu == smp_processor_id())
Satyam Sharma wrote:
Oh wait, the on_one_cpu() patch proposes on UP:
+static inline int on_one_cpu(int cpu, void (*func)(void *info), void
*info,
+ int retry, int wait)
+{
/* this needs a if (cpu == 0) check here, IMO */
+local_irq_disable();
+func(info);
+
On 6/7/07, Avi Kivity [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Oh wait, the on_one_cpu() patch proposes on UP:
+static inline int on_one_cpu(int cpu, void (*func)(void *info), void
*info,
+ int retry, int wait)
+{
/* this needs a if (cpu == 0) check here, IMO */
+
On Fri, 2007-02-09 at 09:42 +0100, Heiko Carstens wrote:
> I just want to avoid that s390 has different semantics for
> smp_call_functiom*() than any other architecture. But then again it
> will probably not hurt since we allow more.
> Another thing that comes into my mind is smp_call_function
On Thu, Feb 08, 2007 at 12:43:28PM -0800, David Miller wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
> Date: Thu, 8 Feb 2007 21:32:10 +0100
>
> > So either all spin_lock_bh's should be converted to spin_lock,
> > which would limit smp_call_function()/smp_call_function_single()
> > to process
On Thu, Feb 08, 2007 at 12:43:28PM -0800, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Thu, 8 Feb 2007 21:32:10 +0100
So either all spin_lock_bh's should be converted to spin_lock,
which would limit smp_call_function()/smp_call_function_single()
to process context
On Fri, 2007-02-09 at 09:42 +0100, Heiko Carstens wrote:
I just want to avoid that s390 has different semantics for
smp_call_functiom*() than any other architecture. But then again it
will probably not hurt since we allow more.
Another thing that comes into my mind is smp_call_function
On Thursday 08 February 2007 21:32, Heiko Carstens wrote:
> On i386/x86_64 smp_call_function_single() takes call_lock with
> spin_lock_bh(). To me this would imply that it is legal to call
> smp_call_function_single() from softirq context.
> It's not since smp_call_function() takes call_lock with
From: Heiko Carstens <[EMAIL PROTECTED]>
Date: Thu, 8 Feb 2007 21:32:10 +0100
> So either all spin_lock_bh's should be converted to spin_lock,
> which would limit smp_call_function()/smp_call_function_single()
> to process context & irqs enabled.
> Or the spin_lock's could be converted to
From: Heiko Carstens [EMAIL PROTECTED]
Date: Thu, 8 Feb 2007 21:32:10 +0100
So either all spin_lock_bh's should be converted to spin_lock,
which would limit smp_call_function()/smp_call_function_single()
to process context irqs enabled.
Or the spin_lock's could be converted to spin_lock_bh
On Thursday 08 February 2007 21:32, Heiko Carstens wrote:
On i386/x86_64 smp_call_function_single() takes call_lock with
spin_lock_bh(). To me this would imply that it is legal to call
smp_call_function_single() from softirq context.
It's not since smp_call_function() takes call_lock with just
26 matches
Mail list logo
