From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
git@vger.kernel.org, pcre-dev@exim.org
Subject: Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
Date: Mon, 10 Dec 2018 09:24:27 +0100 [thread overview]
Message-ID: <87pnu9yekk.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181210004252.GK890086@genre.crustytoothpaste.net>
On Mon, Dec 10 2018, brian m. carlson wrote:
> On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> Obviously this & what you have in 2/2 needs to be fixed in some way.
>>
>> Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the
>> the JIT'd code? I.e. presumably Google Chrome's JIT engine, Java JIT and
>> the like work on those setup, or not? I.e. is this something upstream
>> can/is likely to fix eventually?
>
> From the cover letter (but without testing), it seems like it would
> probably be fine to first map the pages read-write to write the code and
> then, once that's done, to map them read-executable. I know JIT
> compilation does work on the BSDs, so presumably that's the technique to
> make it do so.
>
> Both versions of PCRE map pages both write and executable at the same
> time, which is presumably where things go wrong. I assume it can be
> fixed, but whether that's easy in the context of PCRE, I wouldn't know.
>
>> Are we mixing a condition where one some OS's or OS versions this just
>> won't work at all, and thus maybe should be something turned on in
>> config.mak.uname, v.s. e.g. SELinux where presumably it'll dynamically
>> change.
>
> Considering that some Linux users use PaX kernels with standard
> distributions and that most BSD kernels can be custom-compiled with a
> variety of options enabled or disabled, I think this is something we
> should detect dynamically.
Right. I'm asking whether we're mixing up cases where it can always be
detected at compile-time on some systems v.s. cases where it'll
potentially change at runtime.
>> I'm inclined to suggest that we should have another ifdef here for "if
>> JIT fails I'd like it to die", so that e.g. packages I build (for
>> internal use) don't silently slow down in the future, only for me to
>> find some months later that someone enabled an overzealous SELinux
>> policy and we swept this under the rug.
>
> My view is that JIT is a nice performance optimization, but it's
> optional. I honestly don't think it should even be exposed through the
> API: if it works, then things are faster, and if it doesn't, then
> they're not. I don't see the value in an option for causing things to be
> broken if someone improves the security of the system.
For many users that's definitely the case, but for others that's like
saying a RDBMS is still going to be functional if the "ORDER BY"
function degrades to bubblesort. The JIT improves performance my
multi-hundred percents sometimes, so some users (e.g. me) rely on that
not being silently degraded.
So I'm wondering if we can have something like:
if (!jit)
if (must_have_jit)
BUG(...); // Like currently
else
fallback(); // new behavior
next prev parent reply other threads:[~2018-12-10 8:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-09 23:00 [RFC PATCH 0/2] fallback to interpreter if JIT fails with pcre Carlo Marcelo Arenas Belón
2018-12-09 23:00 ` [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1 Carlo Marcelo Arenas Belón
2018-12-09 23:51 ` Ævar Arnfjörð Bjarmason
2018-12-10 0:42 ` brian m. carlson
2018-12-10 1:25 ` Carlo Arenas
2018-12-10 6:42 ` Junio C Hamano
2018-12-10 8:24 ` Ævar Arnfjörð Bjarmason [this message]
2018-12-11 20:11 ` Carlo Arenas
2018-12-11 20:51 ` Ævar Arnfjörð Bjarmason
2018-12-10 6:54 ` Junio C Hamano
2018-12-10 6:48 ` Junio C Hamano
2018-12-09 23:00 ` [RFC PATCH 2/2] grep: fallback to interpreter if JIT fails with pcre2 Carlo Marcelo Arenas Belón
2018-12-10 7:00 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pnu9yekk.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=pcre-dev@exim.org \
--cc=sandals@crustytoothpaste.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).