linux-kernel - Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e29bcc1-3dc7-40f8-84f0-fbe497fb01bf@gaisler.com>
Date: Thu, 10 Jul 2025 18:22:16 +0200
From: Andreas Larsson <andreas@...sler.com>
To: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Arnd Bergmann <arnd@...db.de>, Arnd Bergmann <arnd@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 "David S . Miller" <davem@...emloft.net>
Cc: Andy Lutomirski <luto@...nel.org>,
 Vincenzo Frascino <vincenzo.frascino@....com>, shuah <shuah@...nel.org>,
 Anna-Maria Gleixner <anna-maria@...utronix.de>,
 Frederic Weisbecker <frederic@...nel.org>, John Stultz <jstultz@...gle.com>,
 Stephen Boyd <sboyd@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Eric Biggers <ebiggers@...gle.com>,
 sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

On 2025-07-07 18:05, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Mon, 2025-07-07 at 17:45 +0200, Arnd Bergmann wrote:
>> On Mon, Jul 7, 2025, at 17:22, John Paul Adrian Glaubitz wrote:
>>> Hello Arnd,
>>>
>>> On Mon, 2025-07-07 at 16:46 +0200, Arnd Bergmann wrote:
>>>> Rip out the whole thing and replace it with a minimal stub as we do
>>>> on parisc and uml. This introduces a small performance regression when
>>>> using a libc that is aware of the vdso (glibc-2.29 or higher).
>>>
>>> Can this performance hit quantified in any way?
>>
>> It's trivial to test calling glibc clock_gettime() in a loop
>> on a specific piece of hardware, the difference should largely
>> depend on how long the timer hardware access takes compared
>> to the syscall overhead.
>>
>> On machines that have neither TICK nor STICK clocksource, the
>> simpler version should even be minimally faster, on those that
>> have one of the two, there is an added cost for entering the
>> syscall on every clock_gettime() as we do on architectures without
>> vdso.
> 
> OK, thanks. Since Andreas has access to a SPARC T4 as of recently, he should
> be able to test this. Please allow some time for him to review and test the
> changes, so we can be sure this doesn't cause any serious regressions.

I tested this patch (running Linux in an LDOM under Solaris) and
measuring the cost of clock_gettime(), running millions of calls. The
calls takes around 13-15 times as long (from around 82-94 nanoseconds
per call to around 1220 nanoseconds per call) with this patch compared
to without, so not an insignificant performance regression in this
environment.

Cheers,
Andreas