Hi!
> > > - raw_notifier_call_chain(&cpu_chain, CPU_LOCK_ACQUIRE, hcpu);
> > > + if (freeze_processes(FE_HOTPLUG_CPU)) {
> > > + thaw_processes(FE_HOTPLUG_CPU);
> > > + return -EBUSY;
> > > + }
> > > +
> >
> > If I'm understanding correctly, this will cause
> >
> > # echo 0 > /sys/devices/system/cpu/cpuX/online
> >
> > to sometimes fail, and userspace is expected to try again? This will
> > break existing applications.
> >
> > Perhaps drivers/base/cpu.c:store_online should retry as long as
> > cpu_up/down return -EBUSY. That would avoid a userspace-visible
> > interface change.
>
> yeah. I'd even suggest a freeze_processes_nofail() API instead, that
> does this internally, without burdening the callsites. (and once the
> freezer becomes complete then freeze_processes_nofail() ==
> freeze_processes())
Not sure if we _can_ do freeze_processes_nofail(). If something is
wrong (process in D state forever because of driver bug?), it looks
better to return error to userspace than looping forever.
You may want to pass higher timeout than 20sec. But if you can't
freeze everything in 1hour, it is unlikely to ever succeed.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
