From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Tomáš Mudruňka" <tomas.mudrunka@gmail.com>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] /proc/sysrq-trigger: accept multiple keys at once
Date: Mon, 13 Nov 2023 16:37:34 -0500	[thread overview]
Message-ID: <2023111330-headstone-pyromania-c57e@gregkh> (raw)
In-Reply-To: <CAH2-hcLoz591mduTVPtFd0ZOEzMNSzhU108qqvv-ZWre7+jm9Q@mail.gmail.com>
On Mon, Nov 13, 2023 at 10:09:50PM +0100, Tomáš Mudruňka wrote:
> po 13. 11. 2023 v 19:33 Greg Kroah-Hartman <gregkh@linuxfoundation.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?
It might be, we can't start doing different functionality just because
we were previously ignoring all the other characters.  Especially for a
user/kernel api that is allowed to reboot the machine :)
> 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?
I'm not, but there is a lot of userspace software out there...
> 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...
I think you are only going to be able to do this "mode switch" method as
we can't potentially break existing systems.  Your change should prevent
that from happening, so at a quick glance, yes, this seems like the only
way forward if this is needed at all (an independent question...)
thanks,
greg k-h
next prev parent reply	other threads:[~2023-11-13 21:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 18:22 [PATCH] /proc/sysrq-trigger: accept multiple keys at once Tomas Mudrunka
2023-11-13 18:33 ` Greg Kroah-Hartman
2023-11-13 21:09   ` Tomáš Mudruňka
2023-11-13 21:37     ` Greg Kroah-Hartman [this message]
2023-11-14  9:35       ` [PATCH v2] " Tomas Mudrunka
2023-11-14  9:44         ` Jiri Slaby
2023-11-14  9:49           ` [PATCH v3] " Tomas Mudrunka
2023-11-14  9:50             ` Jiri Slaby
2023-11-14  9:55               ` [PATCH v4] " Tomas Mudrunka
2023-11-14 12:14                 ` Greg KH
2023-11-14 12:41                   ` [PATCH v5] " Tomas Mudrunka
2023-11-14 15:12                     ` [PATCH v6] " Tomas Mudrunka
2023-11-14 18:04                       ` Jiri Slaby
2023-11-14 22:00                         ` Randy Dunlap
2023-11-15 10:10                           ` Jiri Slaby
2023-11-15 10:27                             ` [PATCH v7] " Tomas Mudrunka
2023-11-15 10:29                             ` [PATCH v8] " Tomas Mudrunka
2023-11-15 10:34                             ` [PATCH v9] " Tomas Mudrunka
2023-11-20  7:45                               ` Jiri Slaby
2023-11-20 11:14                                 ` [PATCH v10] " Tomas Mudrunka
2023-11-20 11:32                                   ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox
  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=2023111330-headstone-pyromania-c57e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=tomas.mudrunka@gmail.com \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).