Re: [PATCH v2] grep: fall back to interpreter if JIT memory allocation fails

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 30, 2023, 18:49 UTC
Message-ID: <xmqq8rhj504i.fsf@gitster.g>
In-Reply-To: <230130.867cx4s2j4.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> If I compile libpcre2 with JIT support I'm expecting Git to use that,
> and not fall back in those cases where the JIT engine would give up.

The thing is, the reason why their Git has JIT enabled pcre2 for many users is not because they choose to compile their own Git for themselves because they wanted to play with JIT. To them, their distro and/or their employer gave a precompiled Git, in the hope that with JIT would be faster than without JIT when JIT is usable.

In that context, "Speed is a feature in itself" is correct but "failing fast, forcing the user to try different things" is not a "Speed" feature at all. It may be interesting only for those who are curious to see what pattern was rejected by JIT. It is especially true as (1) we are willing to fall back to interpreter in the SELinux senario, and (2) for normal users who want to use Git, and not necessarily interested in playing with JIT, there is no other recourse than prefixing "I do not want this JITted" to their pattern ANYWAY. Why fail fast and force the user to take the only recourse manually, when the machinery already knows what the user's only viable alternative is (i.e. falling back to the interpreter)?

> Pathological regexes are pretty much only interesting to anyone in the
> context of DoS attacks where they're being used to cause intentional
> slowdowns.

Exactly.

> Here we're discussing an orthagonal case where the "JIT fails", but
> rather than some pathological pattern it's because SELinux has made it
> not work at runtime, and we're trying to tease the two cases apart.

s/and we're/but you're/.  And I do not think you want to.

> I don't think this is plausible at all per the above, and that we
> shouldn't harm realistic use-cases to satisfy hypothetical ones.

To me, what you are advocating is exactly the hypothetical ones that harm end-users who did not choose to enable JIT themselves. When JIT fails for whatever reason (including the SELinux senario) for them, they do not need to be told by Git failing, when the interpreter can give them the correct answer. Wanting to see the result of the operation they asked Git to do, while allowing Git to use clever optimizations WHEN ABLE, is what I see as realistic use-cases.