[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH2-hcLoz591mduTVPtFd0ZOEzMNSzhU108qqvv-ZWre7+jm9Q@mail.gmail.com>
Date: Mon, 13 Nov 2023 22:09:50 +0100
From: Tomáš Mudruňka <tomas.mudrunka@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Jiri Slaby <jirislaby@...nel.org>, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org
Subject: Re: [PATCH] /proc/sysrq-trigger: accept multiple keys at once
po 13. 11. 2023 v 19:33 Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> What did you just break where people would send a string and only relied
> on the first character being checked? This might not be ok to do.
It truly might not be ok. But i hope you will not consider me impolite
if i open further discussion. Is this actual use case for some people?
I understand that it might be, but currently i can only think about
this being done by mistake, rather than on purpose... are you aware of
any software actually leveraging this feature?
Please also note that there is really good use case for this. if i do
the REISUB bash loop as suggested, the bash will be killed during E or
I and the rest of emergency procedure will not finish. Therefore i
really think it makes sense to be able to pass whole sysrq batch to
the kernel at once.
In case you are sure that this is a bad idea, i can suggest
alternative approach. only activate the "bulk mode" when first
character is '_' (underscore).
User would then be able to do
echo _reisub > /proc/sysrq-trigger
Would you prefer if i do it this way? In my opinion it does introduce
little unnecessary complexity, to fix something that might arguably
not be actual issue. I mean... we still have /dev/null in case people
need to discard some extra characters. :-)
But if you think it's better to stay on safe side, i think it's viable
option as well...
> Also, no documentation update?
Will fix this one in v2.
> thanks,
>
> greg k-h
Powered by blists - more mailing lists