From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDF62C3276D for ; Thu, 2 Jan 2020 11:29:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE0F621655 for ; Thu, 2 Jan 2020 11:29:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728228AbgABL3c (ORCPT ); Thu, 2 Jan 2020 06:29:32 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:36751 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728135AbgABL3c (ORCPT ); Thu, 2 Jan 2020 06:29:32 -0500 Received: from mail-qv1-f41.google.com ([209.85.219.41]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M8k65-1ir5Oi3qUL-004kBN; Thu, 02 Jan 2020 12:29:30 +0100 Received: by mail-qv1-f41.google.com with SMTP id o18so14908036qvf.1; Thu, 02 Jan 2020 03:29:29 -0800 (PST) X-Gm-Message-State: APjAAAV8BPCiPeSM5KLBV8looieXCZJ+AERsxfoByh6+uGLNrvTlX40e +kxY54zq4crDG3UnOveQ51eqVxno9qnKf53g+K4= X-Google-Smtp-Source: APXvYqzptO5odenMl+S0N7s3GQhlwCDgPJBBw4XLujkDNgUOvvmeI6k+bBQkXgHWdkBmH6M+qYLFWJ1uMC5oWigZUtc= X-Received: by 2002:a0c:bd20:: with SMTP id m32mr63056221qvg.197.1577964568705; Thu, 02 Jan 2020 03:29:28 -0800 (PST) MIME-Version: 1.0 References: <47701b5fb73cf536db074031db8e6e3fa3695168.1577111365.git.christophe.leroy@c-s.fr> In-Reply-To: From: Arnd Bergmann Date: Thu, 2 Jan 2020 12:29:12 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback To: Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Vincenzo Frascino , Andy Lutomirski , "linux-kernel@vger.kernel.org" , linuxppc-dev , Linux ARM , "open list:BROADCOM NVRAM DRIVER" , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:6xdXzRg9VpWyJjPDxnqKeILf/1Ib2ZdGGXZNLurLjP1YEaW9OWX MBiMEpDPhR0rFp3y+Qfy0qhY+rWB7mBAVqv9yjoypUyhUUebq/Ee2R9xbqIe9aC7sJxOZ9X FXabUM+WPC7UfbKyu6lS0M1ye8+6WCteZ/4RD28MC52NMdEbJ7cmiA0F4Yura0ipln20ceE AiITv0xUUHFzWnCanJKLQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:/iddvcBU3ds=:geESGrCH9H7D8+t0Jy+RCb JqS2xbP93oTlRsxVSlcuv+KBl1MfH8lIYs/3ZbNXXxbjAn0K6O4GWvbToDuba7Pmw9KLVqGya w43Ogf9yMZZJoSxGFGS5enGKShS+uYNkzmreDQgOUyuGIlownURMOLD+DMrqNScOIK/bFMpxs Z+0omHEibdO696axuGji7OV1SxEswIr18PZgt/mFCF6UYnNzX9StuuzaYX+Qnq561DslNVxHT WiYNVHMZqiG42tmE7aqNebW5na+fT1lLFX1XLH6QMLdO+RQlUdCJuzX21CkQOpEmisypokgXb sruWQ5ZWqlJumxfiRqurYiXz00m+JTivdvDr9KkljXkppPQvZZKa6wTq/k5xcyiJ56/dM87ze A6hcpdYgf+7u5jE8hlqryV/2XGxJlicHR796F87buGuYqBBrTP7TZM6Rw+v3ufvQCMyN5Co3n VuZTcGcU/2I34NA2W+TM4TWZOmuo138AXFAzHaUzUnZpILM2sbjbAujh5dUpPH587cgZZibRD EP74gEOpUHyhjvNWKDFMeV3HLEks19KFwT0H7CnxsfIqCZkUFvc+MEWnUmSPRfwnEaAsfAw6r zxrwz+qIogRj1BYVSycbXtJChz1JSP1xoy3vwZC298Sn4hJTNOOde3maLPlHYWUCWTrjghKM2 czEB32vXGz4qCxkvQW3+MQ5qU7s5evoc3P1Z2LoiC1mC9VKn8xiaUrKEVH108cVw9aFOuI7GY Fc6Pjn47kP1kUdke54vCQRGVVXqRTo/2kkVIxQinNCi5DSORVuRHOdNaGJnwUbcFIxp/BXsAU OMvngzLJd5v5w2rzOC9eSGUx30qoi190SdFnCbdPFJ7xgnEI0XGSRWqJsZ8b8OT5yGfuc9n3c WRZhzr+pDef76AKC8jvg== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 30, 2019 at 1:27 PM Arnd Bergmann wrote: > On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy wrote: > > +static __always_inline > > +long clock_getres32_fallback(clockid_t _clkid, struct old_timespec32 *_ts) > > +{ > > + struct __kernel_timespec ts; > > + int ret = clock_getres_fallback(clock, &ts); > > + > > + if (likely(!ret && _ts)) { > > + _ts->tv_sec = ts.tv_sec; > > + _ts->tv_nsec = ts.tv_nsec; > > + } > > + return ret; > > +} > > Please change these to call __NR_clock_gettime and __NR_clock_getres_time > instead of __NR_clock_gettime64/__NR_clock_getres_time64 for multiple reasons. > > - When doing migration between containers, the vdso may get copied into > an application running on a kernel that does not support the time64 > variants, and then the fallback fails. > > - When CONFIG_COMPAT_32BIT_TIME is disabled, the time32 syscalls > return -ENOSYS, and the vdso version should have the exact same behavior > to avoid surprises. In particular an application that checks clock_gettime() > to see if the time32 are in part of the kernel would get an incorrect result > here. > > arch/arm64/include/asm/vdso/compat_gettimeofday.h already does this, > I think you can just copy the implementation or find a way to share it. There was a related discussion on this after a vdso regression on mips, and I suggested to drop the time32 functions completely from the vdso when CONFIG_COMPAT_32BIT_TIME is disabled, such as diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S index 00c025ba4a92..605f259fa24c 100644 --- a/arch/powerpc/kernel/vdso32/vdso32.lds.S +++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S @@ -145,10 +145,12 @@ VERSION __kernel_get_syscall_map; #ifndef CONFIG_PPC_BOOK3S_601 +#ifdef CONFIG_COMPAT_32BIT_TIME __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres; __kernel_time; +#endif __kernel_get_tbfreq; #endif __kernel_sync_dicache; Any opinions on this? If everyone agrees with that approach, I can send a cross-architecture patch to do this everywhere. It's probably best though if Christophe adds that to his series as it touches a lot of the same files and I would prefer to avoid conflicting changes. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63C54C2D0DC for ; Thu, 2 Jan 2020 11:32:17 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C797521655 for ; Thu, 2 Jan 2020 11:32:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C797521655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47pQqf3J8nzDqC8 for ; Thu, 2 Jan 2020 22:32:14 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.17.13; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47pQmg5FnwzDq99 for ; Thu, 2 Jan 2020 22:29:37 +1100 (AEDT) Received: from mail-qv1-f41.google.com ([209.85.219.41]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M8QJq-1irMNe1zk0-004Ozd for ; Thu, 02 Jan 2020 12:29:30 +0100 Received: by mail-qv1-f41.google.com with SMTP id l14so14872544qvu.12 for ; Thu, 02 Jan 2020 03:29:29 -0800 (PST) X-Gm-Message-State: APjAAAXY4RMgoTkyLBiO30iAQEp3beZ8K3WGiH7savuIpgf+IijRjw5v GHLYxO1gg6/4kdGA5+KnmMUwNcNgVv5WCbsTh7k= X-Google-Smtp-Source: APXvYqzptO5odenMl+S0N7s3GQhlwCDgPJBBw4XLujkDNgUOvvmeI6k+bBQkXgHWdkBmH6M+qYLFWJ1uMC5oWigZUtc= X-Received: by 2002:a0c:bd20:: with SMTP id m32mr63056221qvg.197.1577964568705; Thu, 02 Jan 2020 03:29:28 -0800 (PST) MIME-Version: 1.0 References: <47701b5fb73cf536db074031db8e6e3fa3695168.1577111365.git.christophe.leroy@c-s.fr> In-Reply-To: From: Arnd Bergmann Date: Thu, 2 Jan 2020 12:29:12 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback To: Christophe Leroy Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:RRCSu8LaEPC5fIu/JjFLQsxBjGqv7dwDQfyqVTAcZGsGqse7Nu7 UjisbR2ud3sWb/J0A3G1LnnQ8lONe5KwIGafb0T0RFryx4LoQvA19STScC/Jaxwxo8fYDsJ HMtjbjv6WM6dWuAw3RTMRjWkr61rdbSHqBvj1anV3ymPfJo3DWXCMkF4Hi2C6SeaLk/QBsw hl8c9BNSGF7Zj63eLL5Eg== X-UI-Out-Filterresults: notjunk:1;V03:K0:flXPmYDafLA=:vGmrKevn7YiqpeaGBiod7b 7KrL0IH20lj7l5UrRWb37enJeT4KKizOW9vJ8ns/vZAvUmBnWqxj0/QGWQo308Zl+smGY9A+T TW3s1NSTzwAVKfMSyoB/QOwIqq/oXjx9fYULxCJ+ExS9Cm8wLOAsGw1gkjMnYp+pGUhMuJuXW 8UJ9pkyzukJq2sfEzjzrTGeqOS+BV/gKDO2YYC3qePuKGEYDIwHP5yYeTSKunjXSCsT1mrp7p hnFCPJG3D0iQXlATw9Fe2BET7naLV++r0pQO85hCI4fZBg54QDvHKqxB5fKCocc+ASgy1bTQy DgjNgzeP7SQGCaMipJfQ8VgLch/tsIWqxC5+/yMnIlf7v64SPp6v+IqX6gZ7RX43kzGpBuQ3u sP6sQYjTz218r/muftwUWAJSBW77/t9POa53TyJu41GwNq/EpkRy7nQxyxQrAUoh04+94IoEB wa5nFnVxxTSLR91ciEwmAPxxXDcbfODtRciO7JzBDAOYbYcBu22VfTFFGccMAGX+1KBpQdH04 aF0YNOd8VpONFtt6+BuXgBlh7EqfR2/qORNCq3zK9hHjk7zyv/W9Z58YyhF3RB0BazWmWTADG PRWbTwTBKyHZIpKgKDCaiFytfQNV2oJ9GOVte4CuYM8CQJ1XR4lNoYwmuxvT+7BKFSmHxfe1e AUNZdBq2kqtcWU0raOyw+fEy80LmiTaq63hPBxVcGV5vuj8ApR+fGHRV7SDoiMhXVC+ou0apJ 9vDZCJYu0jhHnDy3LkD90Xk+YE5Zaz10iosr0RQJ9RrqLqweKyIfblTDYRVUEzEIqj1OggVmo Dp8R+K7cZzeyqKb4x/8d8YI7EemxcxDln5j+Cw/i86BuZYtbtROxnnwrexU3jcjPqRFCvW7DW ZvBT05lER3uqjcF8kh/A== X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: the arch/x86 maintainers , "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Paul Mackerras , Andy Lutomirski , Thomas Gleixner , Vincenzo Frascino , linuxppc-dev , Linux ARM Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Dec 30, 2019 at 1:27 PM Arnd Bergmann wrote: > On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy wrote: > > +static __always_inline > > +long clock_getres32_fallback(clockid_t _clkid, struct old_timespec32 *_ts) > > +{ > > + struct __kernel_timespec ts; > > + int ret = clock_getres_fallback(clock, &ts); > > + > > + if (likely(!ret && _ts)) { > > + _ts->tv_sec = ts.tv_sec; > > + _ts->tv_nsec = ts.tv_nsec; > > + } > > + return ret; > > +} > > Please change these to call __NR_clock_gettime and __NR_clock_getres_time > instead of __NR_clock_gettime64/__NR_clock_getres_time64 for multiple reasons. > > - When doing migration between containers, the vdso may get copied into > an application running on a kernel that does not support the time64 > variants, and then the fallback fails. > > - When CONFIG_COMPAT_32BIT_TIME is disabled, the time32 syscalls > return -ENOSYS, and the vdso version should have the exact same behavior > to avoid surprises. In particular an application that checks clock_gettime() > to see if the time32 are in part of the kernel would get an incorrect result > here. > > arch/arm64/include/asm/vdso/compat_gettimeofday.h already does this, > I think you can just copy the implementation or find a way to share it. There was a related discussion on this after a vdso regression on mips, and I suggested to drop the time32 functions completely from the vdso when CONFIG_COMPAT_32BIT_TIME is disabled, such as diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S index 00c025ba4a92..605f259fa24c 100644 --- a/arch/powerpc/kernel/vdso32/vdso32.lds.S +++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S @@ -145,10 +145,12 @@ VERSION __kernel_get_syscall_map; #ifndef CONFIG_PPC_BOOK3S_601 +#ifdef CONFIG_COMPAT_32BIT_TIME __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres; __kernel_time; +#endif __kernel_get_tbfreq; #endif __kernel_sync_dicache; Any opinions on this? If everyone agrees with that approach, I can send a cross-architecture patch to do this everywhere. It's probably best though if Christophe adds that to his series as it touches a lot of the same files and I would prefer to avoid conflicting changes. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84003C2D0DC for ; Thu, 2 Jan 2020 11:29:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5523721655 for ; Thu, 2 Jan 2020 11:29:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MVoEQxRK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5523721655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fo91nKt+HxPvvq3kE6pVrl1cPCGrAZd3asT6p/VWRY4=; b=MVoEQxRKE+h0LB ydkMIKqxc2edLLFsz2XZmrsNwaDntz0qeQ5oGSEGa0oXT8PpDV46IlhbmFhhdKU5PAGeKOG5FHkm2 +qtzRaJnKEeQ7BLRLRGS1I4hOG+Xpq97uB1oPWGvde2HnAMn1pWtPIzIASvSOzOewg9Aoy8fYdiLp DItZVxOaAeKxUkUtdZrujQ2dOJCWcZK08z2q0WVTScfbg+cr3l6OjWcmk4hCsvT3DnPGCnyjOl85C QisEC26/Fh1uER0XLab9Aqg09utTWfneDsmkmDTlDI9RDop8Ip8J8EowDrhn6Le3tWgKlQWkKzXB+ 4aS8pUNorm4TGuaIMJbQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1imyfc-0005vc-3L; Thu, 02 Jan 2020 11:29:40 +0000 Received: from mout.kundenserver.de ([212.227.126.131]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1imyfY-0005uq-IV for linux-arm-kernel@lists.infradead.org; Thu, 02 Jan 2020 11:29:38 +0000 Received: from mail-qv1-f42.google.com ([209.85.219.42]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MOQu6-1j69At3Rni-00Prla for ; Thu, 02 Jan 2020 12:29:30 +0100 Received: by mail-qv1-f42.google.com with SMTP id u10so14819545qvi.2 for ; Thu, 02 Jan 2020 03:29:29 -0800 (PST) X-Gm-Message-State: APjAAAUjerySzAUtfQKjZNKojF0qWEHm2Jl87uNEDDy/9ZbgEdIQNr2Z mm2SnoszN/D05qFK51XkE+tHIIs3/kouUnsd8XY= X-Google-Smtp-Source: APXvYqzptO5odenMl+S0N7s3GQhlwCDgPJBBw4XLujkDNgUOvvmeI6k+bBQkXgHWdkBmH6M+qYLFWJ1uMC5oWigZUtc= X-Received: by 2002:a0c:bd20:: with SMTP id m32mr63056221qvg.197.1577964568705; Thu, 02 Jan 2020 03:29:28 -0800 (PST) MIME-Version: 1.0 References: <47701b5fb73cf536db074031db8e6e3fa3695168.1577111365.git.christophe.leroy@c-s.fr> In-Reply-To: From: Arnd Bergmann Date: Thu, 2 Jan 2020 12:29:12 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback To: Christophe Leroy X-Provags-ID: V03:K1:OeaVzXnj9I+HniTCafYWiZjiYNofva7iSwltwn0d9pMN7R7Pz5y Pqa/XJAYsvRHoaB0H6m/X6ZbEiXPTBCJJ0dgfShGyUOhzEgV85aDJhHbhJYCweNHztd0RVK BhcHQI6Mi8LR3Q8tsfy21+wdxdiqOZ/GyvsdFFZPBIKgnmjjPNigagybudwCFkr9vQxQKAs dIMhbi9EbFVcf32O4Kuow== X-UI-Out-Filterresults: notjunk:1;V03:K0:wadi0JQu4AM=:3p3a0H+XwK8PFwIMesztXy +MCGAEvZ+1UuRWSTMLb5b3qGStMJoFL+r/jB5lhXbfs8F+jFnf63LIh682PUkNaZd2Ik3ZYaJ +RatiGYs6tEKK2zSoB1zWNg8m664MCoyYRgAbR8n6OsJM/9OjhJ1uhgyLwUwWePlocdZBML9X 814iyxny4L6VTQb3gqkWd2Iji/B7cCaPnkxfxPhjFJxTWu6b0x1pO72n2MBqWctTiMEWlYg8I CIn2BmWuLJ++jAdU2lvZbVmUoGcsPDh6wlxB1MeeXXL7n1pD6js3BZOx35bm7fjO1lHmZ6cF/ l6vgXcvPNS4jA9EwPIU1OTpmakOLv2HyM81gSKH/Pmrd3ytUI/Ca780dT9TBNaPQrOLf8mIZb a5u1SGv6jv0GAwCeY6+IfzpMvRVF3X8n+SWjChYKx9M1HUpYo0/MSK//7yhrH7wppEdb7w5u2 GqR2PLqUpxkusbuk6NhidJw8KSh2ynfa4ycez8LsS6lolKDf6esUrbRIv5d3ichf8NIyX4EWI Trai2oN4GRXwwKx68giajC4VQ9Owgg2BKezJyzlcciUJa8sV6X2La/UN626v4EUgbLSLb0yaS wYmzZR2WUaIAKk7IowueGyIfo6yfB/IslIK/bME6NcbjA2d3fEAzGQnMC/i1qUAsjGURhjCLJ dTvwQqW4DkeAPKaKJO5CqGjswW81RlZEc3ipONmwXLK0ekiMFG0P+QN9kWY5K5zB8l0uxivT/ JIYq20zeBe5ngYBvbTS2hfx3vYF4pnBlf5p4oA1i7xw0GD7gIHLE7rqg2ZZzVEndFPC5V2LSP rhPQaB11musmxGWRA6INwtiLaN9lfbmH08P/LSIinOB+qv6aFJrgFdDgVyPAw3o8lhmvO5+01 n4QQ9qHE4QN9lzGc/Aeg== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200102_032936_908021_E5D791BA X-CRM114-Status: GOOD ( 18.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Benjamin Herrenschmidt , the arch/x86 maintainers , "linux-kernel@vger.kernel.org" , "open list:BROADCOM NVRAM DRIVER" , Paul Mackerras , Andy Lutomirski , Michael Ellerman , Thomas Gleixner , Vincenzo Frascino , linuxppc-dev , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 30, 2019 at 1:27 PM Arnd Bergmann wrote: > On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy wrote: > > +static __always_inline > > +long clock_getres32_fallback(clockid_t _clkid, struct old_timespec32 *_ts) > > +{ > > + struct __kernel_timespec ts; > > + int ret = clock_getres_fallback(clock, &ts); > > + > > + if (likely(!ret && _ts)) { > > + _ts->tv_sec = ts.tv_sec; > > + _ts->tv_nsec = ts.tv_nsec; > > + } > > + return ret; > > +} > > Please change these to call __NR_clock_gettime and __NR_clock_getres_time > instead of __NR_clock_gettime64/__NR_clock_getres_time64 for multiple reasons. > > - When doing migration between containers, the vdso may get copied into > an application running on a kernel that does not support the time64 > variants, and then the fallback fails. > > - When CONFIG_COMPAT_32BIT_TIME is disabled, the time32 syscalls > return -ENOSYS, and the vdso version should have the exact same behavior > to avoid surprises. In particular an application that checks clock_gettime() > to see if the time32 are in part of the kernel would get an incorrect result > here. > > arch/arm64/include/asm/vdso/compat_gettimeofday.h already does this, > I think you can just copy the implementation or find a way to share it. There was a related discussion on this after a vdso regression on mips, and I suggested to drop the time32 functions completely from the vdso when CONFIG_COMPAT_32BIT_TIME is disabled, such as diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S index 00c025ba4a92..605f259fa24c 100644 --- a/arch/powerpc/kernel/vdso32/vdso32.lds.S +++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S @@ -145,10 +145,12 @@ VERSION __kernel_get_syscall_map; #ifndef CONFIG_PPC_BOOK3S_601 +#ifdef CONFIG_COMPAT_32BIT_TIME __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres; __kernel_time; +#endif __kernel_get_tbfreq; #endif __kernel_sync_dicache; Any opinions on this? If everyone agrees with that approach, I can send a cross-architecture patch to do this everywhere. It's probably best though if Christophe adds that to his series as it touches a lot of the same files and I would prefer to avoid conflicting changes. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel