On 04/01/2023 14:41, Herbert Xu wrote:
On Wed, Jan 04, 2023 at 02:30:00PM +0000, Harald van Dijk wrote:
In theory, yes. In practice, because of the default Linux overcommit
behaviour, that is not going to happen, that's going to cause the OOM killer
to kick in and forcibly kill the whole process without any way of handling
it. Either that, or forcibly kill some other process that we get no
indication of.
Even if we change the overcommit settings, I'm struggling to think of any
situation where parsing fails because we run out of memory, but freeing the
memory we've already allocated for parsing that one line of input frees
enough to allow us to meaningfully continue.
ckmalloc is just an example. It could really come from anywhere.
For example, expandstr calls expandarg, which could trigger an
exception for SIGINT. Indeed, getting SIGINT directly while in
the parser would also do the trick.
The only place expandstr() is called in the parser is in getprompt(),
which is only called when we're at the start of a line and reading the
next line of input is probably wrong.
As for a SIGINT during actual parsing, that's true. I'm not sure reading
the rest of the input line is always the right thing to do in that case
either. Imagine the user typing
echo 1 <^C> echo 2 <return>
Normally we want this 'echo 2' to be interpreted as a new command. It
seems odd to me to say that we interpret the 'echo 2' as a new command,
*except* if the Ctrl-C is processed early, and the 'echo 2' is entered
early too, in which case we discard it. Especially if this special
exception only applies if "early" is so early that it cannot reliably be
triggered. I would want this to be deterministic.
As long as we're talking about things like that, regardless of how it's
implemented, we could also get another SIGINT during the skipping of the
rest of the input line.
Cheers,
Harald van Dijk
