From: Junio C Hamano <gitster@pobox.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Subject: Re: [PATCH v2] grep: fall back to interpreter if JIT memory allocation fails
Date: Mon, 30 Jan 2023 10:54:23 -0800 [thread overview]
Message-ID: <xmqq357r4zvk.fsf@gitster.g> (raw)
In-Reply-To: <9b5a1113-84f1-1651-bffc-6382462057dd@grsecurity.net> (Mathias Krause's message of "Mon, 30 Jan 2023 12:08:45 +0100")
Mathias Krause <minipli@grsecurity.net> writes:
> My patch doesn't make it worse than what 'git grep' would currently be
> doing. On the contrary, actually. It allows me to use PaX's MPROTECT and
> have a functional 'git grep' as well.
I know. But then without the "why did it fail?" logic (i.e. the v1
patch), it does not make it worse than the current code, either, and
of course allows you to use JIT-enabled pcre2 even where JIT is
impossible due to MPROTECT and whatever reasson.
> Maybe the missing piece here is simply something like below to make
> users more aware of the possibility to disable the JIT for the more
> complex cases?:
If we were to keep that "die", it is absolutely required, I would
think. Users who got their Git with JIT-enabled pcre2 may be
viewing JIT merely as "a clever optimization the implementation is
allowed to use when able", without knowing and more importantly
without wanting to know how to disable it from within their
patterns.
But can't we drop that die() if we took the v1 route?
> diff --git a/grep.c b/grep.c
> index 59afc3f07fc9..1422f168b087 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -357,7 +357,8 @@ static void compile_pcre2_pattern(struct grep_pat
> *p, const struct grep_opt *opt
> p->pcre2_jit_on = 0;
> return;
> } else if (jitret) {
> - die("Couldn't JIT the PCRE2 pattern '%s', got
> '%d'\n", p->pattern, jitret);
> + die("Couldn't JIT the PCRE2 pattern '%s', got
> '%d'%s\n", p->pattern, jitret,
> + pcre2_jit_functional() ? "\nYou might retry
> by prefixing the pattern with '(*NO_JIT)'" : "");
> }
>
> /*
>
> (Sorry about the wrapped lines, my mailer is just broken. I'll make it a
> proper patch, if such functionality is indeed wanted.)
>
> Thanks,
> Mathias
next prev parent reply other threads:[~2023-01-30 18:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 12:15 [PATCH] grep: fall back to interpreter mode if JIT fails Mathias Krause
2022-12-16 16:12 ` Ævar Arnfjörð Bjarmason
2022-12-16 19:26 ` Mathias Krause
2022-12-16 23:09 ` Junio C Hamano
2022-12-17 2:50 ` Carlo Arenas
2022-12-19 9:00 ` Ævar Arnfjörð Bjarmason
2022-12-20 19:29 ` Mathias Krause
2022-12-20 21:11 ` Ævar Arnfjörð Bjarmason
2023-01-18 14:22 ` Mathias Krause
2023-01-18 15:44 ` Ævar Arnfjörð Bjarmason
2023-01-19 9:19 ` Mathias Krause
2022-12-16 22:52 ` Junio C Hamano
2022-12-20 20:40 ` Mathias Krause
2023-01-27 15:49 ` [PATCH v2] grep: fall back to interpreter if JIT memory allocation fails Mathias Krause
2023-01-27 16:34 ` Junio C Hamano
2023-01-27 17:39 ` Junio C Hamano
2023-01-27 18:46 ` Junio C Hamano
2023-01-29 13:37 ` Mathias Krause
2023-01-29 13:36 ` Mathias Krause
2023-01-29 17:15 ` Junio C Hamano
2023-01-30 10:56 ` Ævar Arnfjörð Bjarmason
2023-01-30 18:49 ` Junio C Hamano
2023-01-31 8:34 ` Ævar Arnfjörð Bjarmason
2023-01-30 11:08 ` Mathias Krause
2023-01-30 18:54 ` Junio C Hamano [this message]
2023-01-30 20:08 ` Junio C Hamano
2023-01-30 21:21 ` Junio C Hamano
2023-01-30 22:30 ` Ramsay Jones
2023-01-30 23:27 ` Junio C Hamano
2023-01-31 7:48 ` Mathias Krause
2023-01-31 16:41 ` Junio C Hamano
2023-01-31 18:34 ` Mathias Krause
2023-01-31 7:30 ` Mathias Krause
2023-01-29 12:28 ` Mathias Krause
2023-01-31 18:56 ` [PATCH v3] " Mathias Krause
2023-01-31 21:05 ` Junio C Hamano
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=xmqq357r4zvk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=minipli@grsecurity.net \
/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).