From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 135C33858C27 for ; Fri, 10 Dec 2021 12:51:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 135C33858C27 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-215-q_hVQfTlO1abjQJwnb_t0Q-1; Fri, 10 Dec 2021 07:51:26 -0500 X-MC-Unique: q_hVQfTlO1abjQJwnb_t0Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4ED351023F4D; Fri, 10 Dec 2021 12:51:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08C3045D74; Fri, 10 Dec 2021 12:51:23 +0000 (UTC) From: Florian Weimer To: Arnd Bergmann Cc: Adhemerval Zanella , Adhemerval Zanella via Libc-alpha , Zack Weinberg Subject: Re: [PATCH] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) 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> Date: Fri, 10 Dec 2021 13:51:21 +0100 In-Reply-To: (Arnd Bergmann's message of "Fri, 10 Dec 2021 13:48:03 +0100") Message-ID: <874k7gaaie.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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:51:31 -0000 * Arnd Bergmann: > 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. Thanks, Florian