Re: [PATCH v3 2/2] tty/sysrq: Add configurable handler to execute a compound action

On Fri, Oct 02, 2020 at 05:06:54PM +0200, Andrzej Pietrasiewicz wrote:

Hi,

W dniu 02.10.2020 o 16:02, Greg Kroah-Hartman pisze:

quoted

On Fri, Oct 02, 2020 at 03:42:52PM +0200, Andrzej Pietrasiewicz wrote:

quoted

Hi,

W dniu 02.10.2020 o 14:54, Greg Kroah-Hartman pisze:

quoted

On Tue, Aug 18, 2020 at 01:28:25PM +0200, Andrzej Pietrasiewicz wrote:

quoted

Userland might want to execute e.g. 'w' (show blocked tasks), followed
by 's' (sync), followed by 1000 ms delay and then followed by 'c' (crash)
upon a single magic SysRq. Or one might want to execute the famous "Raising
Elephants Is So Utterly Boring" action. This patch adds a configurable
handler, triggered with 'C', for this exact purpose. The user specifies the
composition of the compound action using syntax similar to getopt, where
each letter corresponds to an individual action and a colon followed by a
number corresponds to a delay of that many milliseconds, e.g.:

ws:1000c

or

r:100eis:1000ub

A macro language for sysrq commands, who would have thought...

Anyway, _why_ would userland want to do something so crazy as this?
What is the use-case here?

A use-case is Chromebooks which do want to execute 'w', 's',
wait 1000ms and then 'c' under one key combination. Having that supported
upstream brings us one little step closer to those machines running
upstream kernel.

Who is causing that to "execute"?  Some daemon/program?

No, as far as I know they patch the kernel to change the behavior
of Sysrq-x combination, so the "execution" is triggered by the user.

So this isn't coming from the chromeos team, so there is no guarantee
that they will switch to this if it is merged?

quoted

quoted

Another argument for such a "macro language" is when a machine's system
keeps degrading over time, possibly degrading (relatively) fast.
"Raising Elephants Is So Utterly Boring" consists of 6 actions, each
of which requires pressing several keys. The user might be unable
to complete all the 6 steps, while a "macro" requires user's involvement
for carrying out just one step.

So you want to "preload" some commands ahead of time, for when you get
in trouble

It can be said this way, yes.

quoted

These should just be debugging / last resort types of things, how
regular are they being used in your systems?

The "REISUB" itself is a kind of a last resort thing.

It is true that it's not a very frequent situation, but does its being rare
preclude having such a function in the kernel?

While preparing this patch I wanted it to be flexible, but perhaps it is
too flexible for some reason? If the permissions of the module_param's
sysfs entry were changed to 0444 would it be better? Then the compound
action would still be configurable but only at boot time rather than at
boot time _and_ runtime.

I don't have an issue with it happening at runtime and boot time, just
that this is adding additional complexity to the kernel (parsers are
fun!) for no real-world user.

thanks,

greg k-h