Re: glibc qsort() vulnerability

Andrey Borodin <x4mmm@yandex-team.ru>

From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>

To: Nathan Bossart <nathandbossart@gmail.com>

Cc: Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>, Mats Kindahl <mats@timescale.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org

Date: 2024-02-09T08:19:49Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Use new overflow-safe integer comparison functions.
- 3b42bdb47169 17.0 landed
Introduce overflow-safe integer comparison functions.
- 6b80394781c8 17.0 landed
Replace calls to pg_qsort() with the qsort() macro.
- 5497daf3aa2a 17.0 landed
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited

> On 8 Feb 2024, at 06:52, Nathan Bossart <nathandbossart@gmail.com> wrote:
> 
> For the same compASC() test, I see an ~8.4% improvement with your int64
> code and a ~3.4% improvement with this:

If we care about branch prediction in comparison function, maybe we could produce sorting that inlines comparator, thus eliminating function call to comparator? We convert comparison logic to int, to extract comparison back then.

I bet “call" is more expensive than “if".

Best regards, Andrey Borodin.