From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by sourceware.org (Postfix) with ESMTPS id 28A2E3858D35 for ; Fri, 10 Dec 2021 13:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28A2E3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=arndb.de Received: from mail-wr1-f42.google.com ([209.85.221.42]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MhDAi-1mHdty2K5S-00eJ2I for ; Fri, 10 Dec 2021 14:11:44 +0100 Received: by mail-wr1-f42.google.com with SMTP id d24so14977310wra.0 for ; Fri, 10 Dec 2021 05:11:44 -0800 (PST) X-Gm-Message-State: AOAM531rJK/HK+baUzm1sdHy31WASoFtK8LsrGHYEGoZj6NYxq1R0zRT R5QPYmObaG9QOfhLTgQAVz65An88YWVCfXI9Lpo= X-Google-Smtp-Source: ABdhPJzCjj4A3GeKLlHzI9FG2aeNIZEDkVy/Tqh8Y3OYEgyZi28XrN5JkD+p2dH0sQA+pXZyr/CloXbI6RMEF+8xr6E= X-Received: by 2002:a5d:64ea:: with SMTP id g10mr14014331wri.137.1639141903856; Fri, 10 Dec 2021 05:11:43 -0800 (PST) MIME-Version: 1.0 References: <20211209191048.4031643-1-adhemerval.zanella@linaro.org> <87r1alegcp.fsf@oldenburg.str.redhat.com> <6ab62b15-6982-0786-3b61-b27c058c4475@linaro.org> <87czm4bsvw.fsf@oldenburg.str.redhat.com> <874k7gaaie.fsf@oldenburg.str.redhat.com> In-Reply-To: <874k7gaaie.fsf@oldenburg.str.redhat.com> From: Arnd Bergmann Date: Fri, 10 Dec 2021 14:11:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) To: Florian Weimer Cc: Arnd Bergmann , Adhemerval Zanella , Adhemerval Zanella via Libc-alpha , Zack Weinberg Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:A137KEPsqZSyAQT0/3q4+wx3qCzL3tANxGGrvjB9xQagqPZ0Zxf gSLzRdnk9WgeIttCsX8FtUmlBnW9GxgzHg98RtHfZjWf0di6ZASr/1EgqJZJkgHx7ghN9x5 /hxA1YwtC7NZnRvIwwWoXap4fHQbyGKoIrfZKuFBazuOBXzqTXBgxi3zofO3wNwPDWfGDsF s4Aeii8tMiN/qHZNyvBtw== X-UI-Out-Filterresults: notjunk:1;V03:K0:cvqQuQnZ0QI=:QAIHfv8RwMi38sZ5fof+JU p5SOF095Y3W9gLYFPq/H3cHl25A5tERV0cS2GG4ied1jKxMLqmR/HNlzy+olb0Fi98Z0D9SGC YoNgruwCY++r1wcdQz1neS4ah6HO6nkffn87SvhpTTEGrmPCl/v0HLjU2HYIgmNbE230tbnUu JXr5KCEfSdSlSrxEgubJsQIPNyUuxK9l6z5/ay8KPfXOKBRIndmLpWJoFZZ4kN4zBMJKSt1Hz r6KhP/t/A1V+vs8nk0mvSa6ZD/sZbMk1W/Yiz56QJh66Sa04en2gzjIfuw4PxPNwpr3sxziIo oFnqKmNUJqkwr0MzUgZoFLkSXe/v4PdDALJ5QrWaTrJA6cIsbJN888g/F/G7vrTLjX1FPbXpj jMBYzBnwj7Lee9nzSiiSJp5U7LWOcCPL3gGOTQyLXhPQUeBNjtr2JJCiNIkk9nt9yNihg6BXh yQPxaqRWYy5reH9QG3kTfoyXZmPKKYhtjxiJ1izjVD6FfIRVNi2tmCl9pcLxrS00yZ3Sk1QOd QWiLZodX5OS3iGZcyL+oYifY//oxeqpNQTqBOU5IH2kufcimPFx9ROOJZwdbzlwhR93YkstMc ekqeYcAgiQvN3jEGdIiRQhEEhIrGric05YqbsMoNL6xwBc2f13BY9IimdjNzNP3OSTINbt0rq T7nVej1gfaFFlwrIRU9l4blFTxtI9hUFbyEMfdTu2KWRhXWMSgStlgbxQc4TO0Hw3budCcyIJ Xh4WEKIiC1nR36L/TWaVOVv2LuvYz+9d3stHzd6MHDIjAYaYQx/y2sK8PHFVQEDt0h5r/Yq29 eylJlIqGAzdljxSl85+NOEEUnYfaMgCwBtYxoeoLWz7g5RuNMw= X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 13:11:47 -0000 On Fri, Dec 10, 2021 at 1:51 PM Florian Weimer wrote: > > On Fri, Dec 10, 2021 at 12:29 PM Florian Weimer wrote: > >> > On Thu, Dec 9, 2021 at 8:35 PM Adhemerval Zanella via Libc-alpha > >> > wrote: > >> >> On 09/12/2021 16:19, Florian Weimer wrote: * Adhemerval Zanella via Libc-alpha: > >> > > >> >> > The change is also not entirely ABI-compatible because existing code on > >> >> > x32 depends on the implementation clearing the upper 32 bits, and if new > >> >> > code copies around structs, it won't necessary copy the zero bits. > >> >> > >> >> Afaiu the high-bits clearing is strictly necessary on kABI boundary for > >> >> set functions. Some issues indeed might arise if user use timespec > >> >> embedded in some function and mix objects built with different glibc > >> >> version, but it is similar to 32-bit architectures with mixing time_t > >> >> objects. > >> > > >> > The kernel's 32-bit ABI ignores the upper 32 bits of tv_nsec for structures > >> > passed from user space, but zeroes them when returning a timespec to user > >> > space. > >> > >> And that zeroing may get lost if the struct has padding. That's my > >> concern. > > > > Which struct? I am talking about __kernel_timespec, which has > > no padding on any architecture, and this is what gets used in the uabi > > headers. > > The proposed new glibc struct timespec for x32. Ok, I don't care then. If anyone is still running x32 user space, they have bigger problems to worry about than the timespec layout. It probably works fine in modern kernels if you make glibc pretend that it's using the normal 32-bit ABI for x32 timespec rather than the one that is declared in the kernel headers (using __kernel_long_t), but I wouldn't stress out about it either way. Arnd