Re: [Fastboot] /x86_64-machine_shutdown.patch breaks sysrq-b

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <akpm@osdl.org> writes:

> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> > Hmm.  Looking a little more closely sysrq-o calls schedule work
> >  which I assume places the code into a context where it can schedule.
> >  Does that sound like a good approach to rebooting as well?
> 
> Not really - if keventd is stuck somewhere, the reboot attempt won't work.
> 
> One could try schedule_work() once, and on the next attempt do something
> drastic I suppose.
> 
> Or just bypass all the shutdown logic and just reboot the machine, dammit -
> is that not possible?

Given the giant variation in hardware out there I don't know if it
is possible in the general case.  The previous code does
seem to work on most hardware.  But I'm not certain it is desirable to
promise something that only works most of the time from a code
maintenance standpoint.    

>From a maintenance standpoint code that is robust and useful from
in an interrupt context is harder to write.  In addition it sets
up a promise to do something that may well be impossible.  

The bottom line is that the various bits and pieces on the reboot
path have such inconsistent semantics that making a correct
change seems to be nearly impossible.  And irritatingly enough
obviously correct pieces of code like calling set_cpus_allowed()
aren't acceptable because they are not interrupt safe.

The bottom line is that if we want correct code on the reboot
path that hole chunk of the kernel needs to ripped apart and put
back together.

Like I said earlier I am torn on how to approach this.  One part
of me wants code that is maintainable without a lot of work,
another part of me want something that just works for the interesting
cases.

The best way I can see to approach this is to rework the code with
the assumption that only sys_reboot() is the only caller who matters.
Fix everything so that case works properly, and has clear semantics.
And then evolve code that is non longer a maintenance nightmare back
to the best effort machine_restart() code in sysrq-B.  My big problem
is I'm not certain if I have enough time to follow through on my
ambitions.

Eric