From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id E3286385AC28 for ; Thu, 27 Jan 2022 12:19:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E3286385AC28 Received: by mail-oi1-x230.google.com with SMTP id w133so5479138oie.7 for ; Thu, 27 Jan 2022 04:19:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Xip/RLiV3HO7oirGH2gncKLhybhRct/911VxGDAlzWA=; b=mdfZEMtyho4dke2yKn+46Cr93XVey8vD7DjcvXtWIjt7dpiO83TNfkPYlbNtdPmYAc I/ywL+TJoSgParwIasAYiH5VFcXY+aNM/suTEDFY+40DIA8Q/AuoD840MKg16HDTU3nv Q7OHU4ZPOJQc1+EwxWyfJ+gak1q+okaEYohmHHIk4CSrVSw7itm0Y4DzOgWw83dibKst S7r4WfVIbKDuYHH06+nhLaAWxgTLcWkZ3XWOGoy5DPVjNT7ZdjJiNo4+n9vu6vFN2uMR tAEZvp3FN34sJ5VjSfDNkRXsdC06Axtd+s2Qk/MV1u4wlN4O3SPxwbzpXiBPcKOIwslx WUYw== X-Gm-Message-State: AOAM531amRWf/11fpA5IptGIGhcfBxx+iDh5XYge9+5Cidd2Qc7v2cSS G4TN18LEN6UeuBIvyRRjazhm/ZG0CIp7gw== X-Google-Smtp-Source: ABdhPJy61NK5MQ9gNK7F35eK/aoBqGdq15cdvLyYcfmhfENI7eHuGcNUrrc5nDVGv/oOksT1zeD8nQ== X-Received: by 2002:aca:ac90:: with SMTP id v138mr1965608oie.228.1643285970270; Thu, 27 Jan 2022 04:19:30 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:27f8:865d:8f66:952e:4ca2? ([2804:431:c7cb:27f8:865d:8f66:952e:4ca2]) by smtp.gmail.com with ESMTPSA id ay32sm3540338oob.16.2022.01.27.04.19.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 04:19:30 -0800 (PST) Message-ID: <16fe263b-fc7a-81ba-dd0e-0979f071a409@linaro.org> Date: Thu, 27 Jan 2022 09:19:27 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v4] linux: Fix ancillary 64-bit time timestamp conversion (BZ #28349, BZ #28350) Content-Language: en-US To: Florian Weimer Cc: Adhemerval Zanella via Libc-alpha 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> <87h79qql4b.fsf@oldenburg.str.redhat.com> <877dalo0ed.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <877dalo0ed.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Thu, 27 Jan 2022 12:19:32 -0000 On 27/01/2022 08:58, Florian Weimer wrote: > * Adhemerval Zanella: > >>> 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. >> >> The MSG_CTRUNC is suppose to be an warning to application would need a large >> buffer for (a), it does not really make sense for (b). I think we can >> improve by adding a recvmsg64 that calls __convert_scm_timestamps and >> remove the conversion on time32 call. > > Right, I expected something like that, which is why I insisted on adding > the time64 symbol aliases. I can work on a patch for 2.35 if you think this is really required. Another options would just to remove the MSG_CTRUNC fro 2.35. > >> It would still need a large buffer for (a), but I expect that time64 >> applications that expects to run on older kernels would need to handle >> it. > > Sounds reasonable to me. > > Thanks, > Florian >