| 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
| ||
|
Message-ID: <ecedb0f1-9543-35c6-18bd-723e6bf21173@csgroup.eu> Date: Wed, 8 Nov 2023 18:31:17 +0000 From: Christophe Leroy <christophe.leroy@...roup.eu> To: Arnd Bergmann <arnd@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Masahiro Yamada <masahiroy@...nel.org>, "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org> CC: Arnd Bergmann <arnd@...db.de>, Matt Turner <mattst88@...il.com>, Vineet Gupta <vgupta@...nel.org>, Russell King <linux@...linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, Guo Ren <guoren@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Ard Biesheuvel <ardb@...nel.org>, Huacai Chen <chenhuacai@...nel.org>, Greg Ungerer <gerg@...ux-m68k.org>, Michal Simek <monstr@...str.eu>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Dinh Nguyen <dinguyen@...nel.org>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Geoff Levand <geoff@...radead.org>, Palmer Dabbelt <palmer@...belt.com>, Heiko Carstens <hca@...ux.ibm.com>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, "David S. Miller" <davem@...emloft.net>, Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "x86@...nel.org" <x86@...nel.org>, Helge Deller <deller@....de>, Sudip Mukherjee <sudipm.mukherjee@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Timur Tabi <timur@...nel.org>, Kent Overstreet <kent.overstreet@...ux.dev>, David Woodhouse <dwmw2@...radead.org>, "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>, Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>, Kees Cook <keescook@...omium.org>, Vincenzo Frascino <vincenzo.frascino@....com>, Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Nicolas Schier <nicolas@...sle.eu>, Al Viro <viro@...iv.linux.org.uk>, Uwe Kleine-König <u.kleine-koenig@...gutronix.de>, "linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>, "linux-snps-arc@...ts.infradead.org" <linux-snps-arc@...ts.infradead.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>, "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>, "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>, "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>, "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>, "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>, "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "linux-bcachefs@...r.kernel.org" <linux-bcachefs@...r.kernel.org>, "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org> Subject: Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes Hi Arnd, Le 08/11/2023 à 13:58, Arnd Bergmann a écrit : > From: Arnd Bergmann <arnd@...db.de> > > The VDSO functions are defined as globals in the kernel sources but intended > to be called from userspace, so there is no need to declare them in a kernel > side header. > > Without a prototype, this now causes warnings such as > > arch/mips/vdso/vgettimeofday.c:14:5: error: no previous prototype for '__vdso_clock_gettime' [-Werror=missing-prototypes] > arch/mips/vdso/vgettimeofday.c:28:5: error: no previous prototype for '__vdso_gettimeofday' [-Werror=missing-prototypes] > arch/mips/vdso/vgettimeofday.c:36:5: error: no previous prototype for '__vdso_clock_getres' [-Werror=missing-prototypes] > arch/mips/vdso/vgettimeofday.c:42:5: error: no previous prototype for '__vdso_clock_gettime64' [-Werror=missing-prototypes] > arch/sparc/vdso/vclock_gettime.c:254:1: error: no previous prototype for '__vdso_clock_gettime' [-Werror=missing-prototypes] > arch/sparc/vdso/vclock_gettime.c:282:1: error: no previous prototype for '__vdso_clock_gettime_stick' [-Werror=missing-prototypes] > arch/sparc/vdso/vclock_gettime.c:307:1: error: no previous prototype for '__vdso_gettimeofday' [-Werror=missing-prototypes] > arch/sparc/vdso/vclock_gettime.c:343:1: error: no previous prototype for '__vdso_gettimeofday_stick' [-Werror=missing-prototypes] > > Most architectures have already added workarounds for these by adding > declarations somewhere, but since these are all compatible, we should > really just have one copy, with an #ifdef check for the 32-bit vs > 64-bit variant and use that everywhere. > > Unfortunately, the sparc version is currently incompatible since > that never added support for __vdso_clock_gettime64() in 32-bit > userland. For the moment, I'm leaving this one out, as I can't > easily test it and it requires a larger rework. > > Signed-off-by: Arnd Bergmann <arnd@...db.de> > --- > arch/arm/include/asm/vdso.h | 5 ----- > arch/arm/vdso/vgettimeofday.c | 1 + > arch/arm64/kernel/vdso32/vgettimeofday.c | 1 + > arch/csky/kernel/vdso/vgettimeofday.c | 11 +---------- > arch/loongarch/vdso/vgettimeofday.c | 7 +------ > arch/mips/vdso/vgettimeofday.c | 1 + > arch/riscv/kernel/vdso/vgettimeofday.c | 7 +------ > arch/x86/entry/vdso/vclock_gettime.c | 10 +--------- > arch/x86/include/asm/vdso/gettimeofday.h | 2 -- > arch/x86/um/vdso/um_vdso.c | 1 + > include/vdso/gettime.h | 23 +++++++++++++++++++++++ > 11 files changed, 31 insertions(+), 38 deletions(-) > create mode 100644 include/vdso/gettime.h 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 ? Christophe
Powered by blists - more mailing lists