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.133.124]) by sourceware.org (Postfix) with ESMTPS id 99C493858D35 for ; Wed, 26 Jan 2022 20:48:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99C493858D35 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-482-oADHXmDxN_qmwyP7fasw9Q-1; Wed, 26 Jan 2022 15:48:24 -0500 X-MC-Unique: oADHXmDxN_qmwyP7fasw9Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 705D51015DA0; Wed, 26 Jan 2022 20:48:23 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9E4E0100EB3B; Wed, 26 Jan 2022 20:48:22 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH v4] linux: Fix ancillary 64-bit time timestamp conversion (BZ #28349, BZ #28350) References: <20211222185239.1088511-1-adhemerval.zanella@linaro.org> <8735lh6vqo.fsf@oldenburg.str.redhat.com> <372ae1ee-0163-7bf4-be1c-cc1f13b1a940@linaro.org> <87bl0149i2.fsf@oldenburg.str.redhat.com> <9263a5c2-48c4-a5d1-c159-2f0ee4e26c52@linaro.org> <87y2352try.fsf@oldenburg.str.redhat.com> <699abc23-7e47-a85f-e553-b5a6c0b1f426@linaro.org> Date: Wed, 26 Jan 2022 21:48:20 +0100 In-Reply-To: <699abc23-7e47-a85f-e553-b5a6c0b1f426@linaro.org> (Adhemerval Zanella's message of "Mon, 24 Jan 2022 10:26:16 -0300") Message-ID: <87h79qql4b.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.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 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: Wed, 26 Jan 2022 20:48:38 -0000 * Adhemerval Zanella: > On 24/01/2022 09:38, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> On 24/01/2022 09:13, Florian Weimer wrote: >>>> * Adhemerval Zanella: >>>> >>>>>> typo: MSG_[C]TRUNC >>>>>> >>>>>> (I think this MSG_CTRUNC result is a remaining bug we need to fix >>>>>> separately for time32 mode.) >>>>> >>>>> Do you mean not returning the MSG_CTRUNC? >>>> >>>> No, if the caller uses CMSG_SPACE to allocate space for the expected >>>> ancillary data, we should not produce MSG_CTRUNC by stuffing in >>>> ancillary data that has not been requested. Maybe we can do this for >>>> time32 code only. Again it seems that userspace emulation is rather >>>> questionable here. >>> >>> But this would be only an issue for applications using _TIME_BITS=64 >>> running on older kernels (so 32 bit timestamps would be visible to >>> the caller). Since 64 bit is a opt-in feature, I think users will >>> see way more potential issues running _TIME_BITS=64 on older kernels. >> >> As far as I can see, it is currently an issue for time32 applications >> running on old and new kernels. We synthesize the time64 control >> messages unconditionally. > > time32 applications running on any kernel will continue to see the > timestamps because they will use the old SO_ constants and kernel will > synthesize them on the ancillary buffer. Will the kernel really produce two timestamps? I thought the kernel kept track which kind of timestamps have been requested and will only emit those. > It might be a problem only when time32 application use the new 64 bit > time_t SO_ constants either though a library built with _TIME_SIZE=64 > or by using it directly (which should not be straightforward since both > kernel and glibc only define the 64 bit constants for _TIME_BITS=64). Are you sure? I think our current recvmsg implementation cannot tell these two cases apart: (a) time64 application running on an old kernel that does not have time64 timestamping support (so time32 setsockopt was used by glibc) (b) time32 application running on any kernel that uses time32 setsockopt In both cases, we generate the time64 timestamp, and that can use to MSG_CTRUNC. This is the systemd failure. DHCP6 broken on armhf (and probably other 32 bit arches) We can fix this in a follow-up patch. Thanks, Florian