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 \ --subject='Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1' \ /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
Code repositories for project(s) associated with this 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).