Re: +pm-introduce-new-interfaces-schedule_work_on-and-queue_work_on.patch addedto -mm tree

[Zhang Rui]

On Thu, 2008-07-24 at 20:43 +0800, Oleg Nesterov wrote:
> On 07/22, Gautham R Shenoy wrote:
> >
> > On Sat, Jul 12, 2008 at 08:21:49PM +0400, Oleg Nesterov wrote:
> > >
> > > So, this is used in
> http://bugzilla.kernel.org/attachment.cgi?id=16707
> > >
> > >     --- linux-2.6.orig/kernel/power/poweroff.c      2008-06-30
> 16:01:35.000000000 +0800
> > >     +++ linux-2.6/kernel/power/poweroff.c   2008-07-03
> 10:50:05.000000000 +0800
> > >     @@ -25,7 +25,8 @@
> > >     
> > >      static void handle_poweroff(int key, struct tty_struct *tty)
> > >      {
> > >     -       schedule_work(&poweroff_work);
> > >     +       /* run sysrq poweroff on boot cpu */
> > >     +       schedule_work_on(first_cpu(cpu_online_map),
> &poweroff_work);
> > >      }
> > >     
> > >      static struct sysrq_key_op     sysrq_poweroff_op = {
> > >
> > > A couple of silly questions, I don't understand the low-level
> details.
> > >
> > > This patch (and kernel_power_off() afaics) assumes that the boot
> cpu
> > > can't be cpu_down()'ed. Is it true in general? For example, grep
> shows
> > > that arch/s390/kernel/smp.c:topology_init()->smp_add_present_cpu()
> > > sets ->hotpluggable = 1 for all present CPUs?
> >
> > I tried this on a Power system sometime back and I was able to
> > offline CPU0.
> 
> This means that
> 
>         pm-schedule-sysrq-poweroff-on-boot-cpu.patch
> 
> is not 100% right. It is still possible to hang/deadlock if we race
> with cpu_down(first_cpu(cpu_online_map)).

Yes, you're right.
But then should we fix disable_nonboot_cpus as well?

int disable_nonboot_cpus(void)
{
        first_cpu = first_cpu(cpu_online_map);
	...
 
        for_each_online_cpu(cpu) {
                if (cpu == first_cpu)
                        continue;
                error = _cpu_down(cpu, 1);
		...
        }
	...
}

thanks,
rui

> The bug is mostly theoretical, but perhaps should be fixed anyway,
> handle_poweroff() can use kthread_run().
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/