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=-5.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 A56EDC432C3 for ; Wed, 13 Nov 2019 21:43:21 +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 2722A206EE for ; Wed, 13 Nov 2019 21:43:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2722A206EE 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 47Cylp66yVzF22y for ; Thu, 14 Nov 2019 08:43:18 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=217.72.192.74; 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 [217.72.192.74]) (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 47CyjR5sxDzF72Z for ; Thu, 14 Nov 2019 08:41:14 +1100 (AEDT) Received: from mail-qt1-f179.google.com ([209.85.160.179]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MVMNF-1iLpoo2OCl-00SQeu for ; Wed, 13 Nov 2019 22:41:09 +0100 Received: by mail-qt1-f179.google.com with SMTP id r20so4269507qtp.13 for ; Wed, 13 Nov 2019 13:41:09 -0800 (PST) X-Gm-Message-State: APjAAAUsR8/yrC6uaDJXcgIRLnOC932Dz8lGGiCrlszBF8TusIKqtW2E ldrie1fpMdy6546v0+lzrjyy88n57smRsR/v1fc= X-Google-Smtp-Source: APXvYqyjRd+a6foxC3+k9qUEopPf1CRknFxQHbHw9aZuys53MC+zVt0jx9JeruKLHIsAWsaGcA9LllqlMRQxiR5o4ug= X-Received: by 2002:a37:4f0a:: with SMTP id d10mr4703334qkb.286.1573681267104; Wed, 13 Nov 2019 13:41:07 -0800 (PST) MIME-Version: 1.0 References: <20191108210236.1296047-1-arnd@arndb.de> In-Reply-To: <20191108210236.1296047-1-arnd@arndb.de> From: Arnd Bergmann Date: Wed, 13 Nov 2019 22:40:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/23] y2038 cleanups To: y2038 Mailman List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:W3bjDzLZF1tKQIYe9JIKsdzbwIL417VikqiVHsmR8O4T2ax7MV1 V+oSCkKpf+J4iMBGxbeNSayOknLodWaYeC2yyNh9Z4bJ3Nce5Zrg9KFf2dSiOhRVIr0Fn87 BHops8fdr4rx8oMXKxTaqQwgHFz3aTZl5jSBLdUR09IhckuNYlvc4YQPVNb3SAleZPXcJ5v MU6djQPcG4BkmyHMqtqLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:g+8iPcENPrk=:S9TCojgPgq2dlzpMsy5RW1 BkgD0NPWxZDPkw2ERzVe/JFzgg30ALwc04zvDNgLj8De9Nxxrunox3+QURmatDJs3kFLqTErC vRq9g+blw3j9ISWpSNb9KXd77wVTi40A8/8PIL/C0EXo/tXHYIvE29QteLmfpbMinauGS5NQA 39enBYSKwC94c9lfoCTkRiwPvpUiLRmrlunHUhjn7t6lc5SDooEiB23ns4Ui0rDQ7UbHkpI2H 3KxT1p1C3XGK5lB+vQf6SwScLt/c2gyHoivNBG/xldmgsqNGPXArmJfif5pqFK4K6h0/3eEog 0FPlhb4tq8hhejxtUrQl+A8aS3tZlYFdJx0yT9zOnoqxqCbwsqYQQeTUOGHUoeS/w5I9gABch 5RLAeZ5rTmTXFnbGd/tQekcubZx3d7TwsKpVNXAtViZ5iD8nTa+hGq5rdXL+rZIUPIQHI8VHc ubOkVpix0UrdKEbAzp+F4RtQdIOMZW60+W49d1lOEhXOZRNhBEaiVj+guBucYF1+UW/g5432T x19zzLxlxRxRe1Cx4Q/Gs14Gip/iFPdubTOiDgzs9MLSTtP0syQx4Yx/iXpkdzVEte4KTESeH WWPDics8++MbiBcoMKkRQYssnBwhXyT5Lgims5PzzkwJbYrXISCYhJu2zQjNPNZEsCiUxqNui df9hWD71S3Lttdfh1fZCItujFUNnvtl2YD13LmutpUFZeU4aQ1mcvolCEAWOL/t8uOUPkb78y ZUMnhTFSKJZ2eTqC6eCEtHPuMv/XdZcJ3s8Pu4GR7wxTE0ZFY+Ry0co+vuC+bIcHfj71Yrhz0 TvqHRTcuCOodG1GxDLDJmAubmjEPVAC1WQFo6Fq1YDadZ92KANXmrN7SxWSd9XFhdyFTDGgfu qoiAaixGZfU2J+m1lCFg== 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: linux-aio , linux-ia64@vger.kernel.org, Peter Zijlstra , Heiko Carstens , linux-mips@vger.kernel.org, Networking , Deepa Dinamani , sparclinux , Vincenzo Frascino , Will Deacon , linux-arch , Paul Moore , Helge Deller , the arch/x86 maintainers , Stephen Smalley , SElinux list , Jeff Dike , alpha , linux-um@lists.infradead.org, Steven Rostedt , John Stultz , Al Viro , Eric Paris , Thomas Gleixner , Christian Brauner , Richard Henderson , Tony Luck , Parisc List , Stephen Boyd , Linux API , "linux-kernel@vger.kernel.org" , Paul Burton , Benjamin LaHaise , "Eric W . Biederman" , Richard Weinberger , Linux FS-devel Mailing List , linuxppc-dev , David Miller , Greentime Hu Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Nov 8, 2019 at 10:04 PM Arnd Bergmann wrote: > > This is a series of cleanups for the y2038 work, mostly intended > for namespace cleaning: the kernel defines the traditional > time_t, timeval and timespec types that often lead to y2038-unsafe > code. Even though the unsafe usage is mostly gone from the kernel, > having the types and associated functions around means that we > can still grow new users, and that we may be missing conversions > to safe types that actually matter. > > As there is no rush on any of these patches, I would either > queue them up in linux-next through my y2038 branch, or > Thomas could add them to the tip tree if he wants. > > As mentioned in another series, this is part of a larger > effort to fix all the remaining bits and pieces that are > not completed yet from the y2038 conversion, and the full > set can be found at: > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame > > Maintainers, please review and provide Acks. > > Let me know if you have any opinion on whether we should do > the include last two patches of this series or not. > > Arnd > > Arnd Bergmann (23): > y2038: remove CONFIG_64BIT_TIME > y2038: add __kernel_old_timespec and __kernel_old_time_t > y2038: vdso: change timeval to __kernel_old_timeval > y2038: vdso: change timespec to __kernel_old_timespec > y2038: vdso: change time_t to __kernel_old_time_t > y2038: vdso: nds32: open-code timespec_add_ns() > y2038: vdso: powerpc: avoid timespec references > y2038: ipc: remove __kernel_time_t reference from headers > y2038: stat: avoid 'time_t' in 'struct stat' > y2038: uapi: change __kernel_time_t to __kernel_old_time_t > y2038: rusage: use __kernel_old_timeval > y2038: syscalls: change remaining timeval to __kernel_old_timeval > y2038: socket: remove timespec reference in timestamping > y2038: make ns_to_compat_timeval use __kernel_old_timeval > y2038: elfcore: Use __kernel_old_timeval for process times > y2038: timerfd: Use timespec64 internally > y2038: time: avoid timespec usage in settimeofday() > y2038: itimer: compat handling to itimer.c > y2038: use compat_{get,set}_itimer on alpha > y2038: move itimer reset into itimer.c > y2038: itimer: change implementation to timespec64 > [RFC] y2038: itimer: use ktime_t internally > y2038: allow disabling time32 system calls I've dropped the "[RFC] y2038: itimer: use ktime_t internally" patch for the moment, and added two other patches from other series: y2038: remove CONFIG_64BIT_TIME y2038: socket: use __kernel_old_timespec instead of timespec Tentatively pushed out the patches with the Acks I have received so far to my y2038 branch on git.kernel.org so it gets included in linux-next. If I hear no complaints, I'll send a pull request for the merge window, along with the compat-ioctl series I have already queued up in the same branch. Arnd