From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by sourceware.org (Postfix) with ESMTPS id CA5463857C59 for ; Fri, 10 Dec 2021 12:48:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA5463857C59 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-wm1-f43.google.com ([209.85.128.43]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MKbc2-1nGTzr3AoW-00L0Bu for ; Fri, 10 Dec 2021 13:48:19 +0100 Received: by mail-wm1-f43.google.com with SMTP id y196so6729293wmc.3 for ; Fri, 10 Dec 2021 04:48:19 -0800 (PST) X-Gm-Message-State: AOAM533rgT0u2z7mflxRPWP8A0dvB8CbTXGJlJJaQFTR4c0iIgDVXrVI vgk63QXaNrj/VyTSpnf3GBV8hZJ2rA8gHhS3lPQ= X-Google-Smtp-Source: ABdhPJzvxqPd+Im9coKRIvv3FuAMkIJSy8jD554LA/PBUPGRMsmGU5gbS3syyjxZmha5EBkT26qgzxmo8VRc1fbonoc= X-Received: by 2002:a1c:23d4:: with SMTP id j203mr15704876wmj.35.1639140499433; Fri, 10 Dec 2021 04:48:19 -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> In-Reply-To: <87czm4bsvw.fsf@oldenburg.str.redhat.com> From: Arnd Bergmann Date: Fri, 10 Dec 2021 13:48:03 +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:VWEuBopWDAQLExNQ21kk/yBqvpRfeloQF60UooERsjSzazhFi0p DNK8OuVHvNQ3I7oDarpNtt+iYnHAyVDkbQIQQASv/Qw/rEIeaTYSk2/2Er/+67YGifJy/Nw RM7NvC/L6bkzWQiMbAh6kOpb2zAYfv76tc3yhfms50mcdrecUVRiz6dif2+czfKN9EL9qFJ n+PCplC2Oybo4pV77QyDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:WDcMZuRpbrs=:ovHp2BspS9VSvQlWwhl4kC kd0Y3mA9c9ZU9o2fabWyfBtn5EzmHUuLkr1EEtunMGxPXvRn6E7qW9NRN+GHmyfWLKQcsowIk p7oYthpaj1SfF5YNMrgq7heWH+Fln563REWjz8JztLJAxOhOkK95N5P+anVcQbi/+HzjatSu2 4pbpn1aPS3F6hKO4DmbkflLXwvj/+P3gS1UFkMFKtMggdivtg5fOa2uvPxprqWQZFk/3rNIc3 2YW4aGVh2YZpJh9nCJovK8cBAD6eCm8QnEqRtLQpuaxDPyIbHepa7mCiLSbHsMNkuPUnVe0yi Vc3Xs62wh3znmEHV6uQLzWv7QYu6sUOr97wJyyW9Z0u2r4/bqZi04LKSeCzOEigJmoulG+m/B qIewyrxCUBnSPaej8FTiRklkB1l9ovwio/k4upolsiZkgLJKqZg4iH+t0rGwhAcx9trsXnlg+ +sDBZ2VJkyfKOXHoVh6UBPnLie7AYqi7czU93uIBxO89hhgKUpZLA+XcFJM6xiYKmrISJRN/O 8Ag/Tlqvfg4wTjvIZXOaIq7/DvAh83RYGPFGq3B3vTzZUX0VFGh59hpcvABu2leFZTrJgPZUS DXg1MztEvWpmRKj9G9X1G9FvOMZDHBxEc4s0GgBMUgePHDECLOjpzRbWSl+IxQ3P4bUB/Vype KVqrB8j0Zs1nxdiV86NhI080K5qiUcPt96hbksq7kvJcVNUSQRLfCoAoAlODJ2xiw6So= X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, 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 12:48:23 -0000 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. Arnd