Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <cover.1587401492.git.christophe.leroy@c-s.fr>
In-Reply-To: <cover.1587401492.git.christophe.leroy@c-s.fr>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 20 Apr 2020 21:57:09 +0200
Message-ID: <CAK8P3a11t=piuDq+TuGMo0xDiN06OLMxsym0PGiWNv5qYSUXLQ@mail.gmail.com>
Subject: Re: [PATCH v7 0/7] powerpc: switch VDSO to C implementation
To:     Christophe Leroy <christophe.leroy@c-s.fr>
Cc:     Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Nathan Lynch <nathanl@linux.ibm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Andy Lutomirski <luto@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 20, 2020 at 6:56 PM Christophe Leroy
<christophe.leroy@c-s.fr> wrote:
>
> This is the seventh version of a series to switch powerpc VDSO to
> generic C implementation.
>
> Main changes since v6 are:
> - Added -fasynchronous-unwind-tables in CFLAGS
> - Split patch 2 in two parts
> - Split patch 5 (which was patch 4) in two parts
>
> This series applies on today's powerpc/merge branch.
>
> See the last two patches for details on changes and performance.
>
> Christophe Leroy (7):
>   powerpc/vdso64: Switch from __get_datapage() to get_datapage inline
>     macro
>   powerpc/vdso: Remove __kernel_datapage_offset and simplify
>     __get_datapage()
>   powerpc/vdso: Remove unused \tmp param in __get_datapage()
>   powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
>   powerpc/vdso: Prepare for switching VDSO to generic C implementation.
>   powerpc/vdso: Switch VDSO to generic C implementation.

This all looks fine, but I'm a bit puzzled why you don't add a
clock_gettime64() implementation in the same series. Isn't
that the main purpose of doing all that work?

Without it, any 32-bit user space has to go through the system call
for time()/getttimeofday()/clock_gettime() when built with a
modern libc.

         Arnd