From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F5131DA34; Thu, 9 Nov 2023 12:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="JOE+Y96n" Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D6C52D55; Thu, 9 Nov 2023 04:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1699532610; bh=R2IIgl4ZRFgwipCQ4ZBWquxZCbtnLxeQT8yMzVcSClk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JOE+Y96nQb0g0fD7YjgIsTtXOrsQ0zdJ9Xit6bae239vdgrtE8Xe20tGEjOEwp6b5 bBGasTtN2qhciM6Vxj5gO1APMLHXfhhNabxTTxDpDoDz6AXcIv0hdu9+rRXuZNmSj3 PriUuPEOny5OCaNxYhuQeMYyhW0D7Uuip11fA5kii4KmxM9zaRV2MnEviCDpMHy6zq fUfZ9elCA6bj44/a3P1CQqNaCruTVzrNA2B2UxDQEd/EBpaSM5DHluHgXy74J1JLYp rlgnpTfcT5fdD0htnPYkbVFENF7DqxPzxI5N3NUPYBgm/lUlPDoiySV3dJVovZ01Br M0UtCQNJ+RaEQ== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4SR1MD6jtmz4wd2; Thu, 9 Nov 2023 23:23:20 +1100 (AEDT) From: Michael Ellerman To: Christophe Leroy , Arnd Bergmann , Arnd Bergmann , Andrew Morton , "linux-kernel@vger.kernel.org" , Masahiro Yamada , "linux-kbuild@vger.kernel.org" Cc: Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Rostedt , Masami Hiramatsu , Mark Rutland , guoren , Peter Zijlstra , Ard Biesheuvel , Huacai Chen , Greg Ungerer , Michal Simek , Thomas Bogendoerfer , Dinh Nguyen , Nicholas Piggin , Geoff Levand , Palmer Dabbelt , Heiko Carstens , John Paul Adrian Glaubitz , "David S . Miller" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , Helge Deller , Sudip Mukherjee , Greg Kroah-Hartman , Timur Tabi , Kent Overstreet , David Woodhouse , "Naveen N. Rao" , Anil S Keshavamurthy , Kees Cook , Vincenzo Frascino , Juri Lelli , Vincent Guittot , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Alexander Viro , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , "linux-alpha@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-trace-kernel@vger.kernel.org" , "linux-csky@vger.kernel.org" , "loongarch@lists.linux.dev" , "linux-m68k@lists.linux-m68k.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "sparclinux@vger.kernel.org" , Netdev , "linux-parisc@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-bcachefs@vger.kernel.org" , "linux-mtd@lists.infradead.org" Subject: Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes In-Reply-To: <886df4e4-9fc2-ca52-e7e9-53688e6e821a@csgroup.eu> References: <20231108125843.3806765-1-arnd@kernel.org> <20231108125843.3806765-16-arnd@kernel.org> <87o7g3qlf5.fsf@mail.lhotse> <886df4e4-9fc2-ca52-e7e9-53688e6e821a@csgroup.eu> Date: Thu, 09 Nov 2023 23:23:20 +1100 Message-ID: <87il6bqfnr.fsf@mail.lhotse> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christophe Leroy writes: > Le 09/11/2023 =C3=A0 11:18, Michael Ellerman a =C3=A9crit=C2=A0: >> "Arnd Bergmann" writes: >>> On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote: >>>> Le 08/11/2023 =C3=A0 13:58, Arnd Bergmann a =C3=A9crit=C2=A0: >>> >>>> powerpc has functions doing more or less the same, they are called >>>> __c_kernel_clock_gettime() and alike with their prototypes siting in >>>> arch/powerpc/include/asm/vdso/gettimeofday.h >>>> >>>> Should those prototypes be moved to include/vdso/gettime.h too and >>>> eventually renamed, or are they considered too powerpc specific ? >>> >>> I don't actually know, my initial interpretation was that >>> these function names are part of the user ABI for the vdso, >>> but I never looked closely enough at how vdso works to >>> be sure what the actual ABI is. >>=20 >> AFAIK the ABI is just the symbols we export, as defined in the linker >> script: >>=20 >> /* >> * This controls what symbols we export from the DSO. >> */ >> VERSION >> { >> VDSO_VERSION_STRING { >> global: >> __kernel_get_syscall_map; >> __kernel_gettimeofday; >> __kernel_clock_gettime; >> __kernel_clock_getres; >> __kernel_get_tbfreq; >> __kernel_sync_dicache; >> __kernel_sigtramp_rt64; >> __kernel_getcpu; >> __kernel_time; >>=20 >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/= arch/powerpc/kernel/vdso/vdso64.lds.S?h=3Dv6.6&#n117 >>=20 >>> If __c_kernel_clock_gettime() etc are not part of the user-facing >>> ABI, I think renaming them for consistency with the other >>> architectures would be best. >>=20 >> The __c symbols are not part of the ABI, so we could rename them. >>=20 >> At the moment though they don't have the same prototype as the generic >> versions, because we find the VDSO data in asm and pass it to the C >> functions, eg: >>=20 >> int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct time= zone *tz, >> const struct vdso_data *vd); >>=20 >> I think we can rework that though, by implementing >> __arch_get_vdso_data() and getting the vdso_data in C. Then we'd be able >> to share the prototypes. > > I think it would not a been good idea, it would be less performant, for=20 > explanation see commit=20 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3De876f0b69dc993e86ca7795e63e98385aa9a7ef3 Ah thanks. I was wondering why you had done it in asm. It's a pity but you're right that's probably a measurable performance hit for some of those calls. cheers