From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 08463383F422 for ; Tue, 6 Jul 2021 12:55:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08463383F422 Received: by mail-pj1-x102d.google.com with SMTP id l11so13459801pji.5 for ; Tue, 06 Jul 2021 05:55:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lKUqCSaj5lPj/IvWdd8cn2v9BtnTMDllVtAJ51HvOEA=; b=jr/ljLOyqTyI7iwvvn3SWWVJxMAgO4TSlysagG+pfV/qtyN13oekIa3s6ZAn3x+s2N 8VU7zUBAiCHQfx+pyA1lhbvdQXblJwoqwBcAO2hlT32H5Ntw3Zd+7codKTTmXe/ztcIn jQdp7EPwTBOGFCB32IogySr/QzM2Lg2Ai3q2z8cSkN3A5haNYGX7nGaFsB+NOsAsgT7u zINYpvA3g40bKMsSl7fim0CqNgnOTkrLR8c82WzVx/UK56mazsMgAuHG9+po+Yu17yZQ kwmkDvB67VA1Ml+2Wcf0jPjMkUAvTeM03eafJnFkDZ1neM+9srHyc5ZVyD2TANiRZwYY d8qg== X-Gm-Message-State: AOAM533X+c4dGtzidXk961w8Zz2rbMuBMyPzXHK5xMw9RQ6bRVYgl1u/ cl3lhzPoMF79QBayn6VxS61IYw== X-Google-Smtp-Source: ABdhPJxmqgfncioHfc6hJQ3nhxM9rTNucPCb6fY7SKVWVGzaYUzfHQ5RAarGaPzQ0Ag+iFDl6GzbAA== X-Received: by 2002:a17:902:7596:b029:127:a1be:f8b2 with SMTP id j22-20020a1709027596b0290127a1bef8b2mr16926426pll.9.1625576113935; Tue, 06 Jul 2021 05:55:13 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id d19sm2844866pjx.57.2021.07.06.05.55.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 05:55:13 -0700 (PDT) Subject: Re: [PATCH 6/7] socket: Add recvmsg timestamp test To: Florian Weimer Cc: Adhemerval Zanella via Libc-alpha , Arnd Bergmann References: <20210705183027.3804093-1-adhemerval.zanella@linaro.org> <20210705183027.3804093-7-adhemerval.zanella@linaro.org> <87a6n0k14u.fsf@oldenburg.str.redhat.com> <5b448e8c-b198-ca44-4357-7c30114d36a9@linaro.org> <875yxojzqb.fsf@oldenburg.str.redhat.com> <36ce3792-17db-0a3d-530d-a1e232a68848@linaro.org> <87a6mziyd4.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Tue, 6 Jul 2021 09:55:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87a6mziyd4.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 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: Tue, 06 Jul 2021 12:55:16 -0000 On 06/07/2021 06:29, Florian Weimer wrote: > * Adhemerval Zanella: > >> On 05/07/2021 17:02, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>>>> + do_test_send (&srv_addr, 1); >>>>>> + do_recvmsg (srv, false, NULL, 0, 0, 0); >>>>>> + >>>>>> + /* If underlying kernel does not support */ >>>>>> + bool support_64_timestamp = support_socket_time64_timestamp (srv); >>>>>> + >>>>>> + /* Enable the timestamp using struct timeval precision. */ >>>>>> + xsetsockopt (srv, SOL_SOCKET, SO_TIMESTAMP, &(int){1}, sizeof (int)); >>>>> >>>>> Please use setsockopt here, nt the x wrapper, so that the ABI switches >>>>> with time64 support. >>>> >>>> Currently it does not matter because SO_TIMESTAMP will be handled by >>>> the kernel headers. >>> >>> With my __setsockopt64 patch, the time64 version of the test will use a >>> different symbol. This is what I meant. >> >> Yeah, I am not really convinced we do need such newer symbols that do >> not correlate to 64-bit time_t syscall since I think it is *highly* >> unlikely kernel will 64-bit time_t facilities for multiplexed syscall >> (and I would consider this a bug) without any guards or checking >> if the program is using 32-bit time_t. > > What about SO_VM_SOCKETS_CONNECT_TIMEOUT? Should we paper over all drivers or kernel features that do not have proper 64-bit support? If so it would add a quite complex multiplex handling on some syscall (ioctl). I would expect we will have quite a few drivers out there which miss proper 64-bit support. I added support for SO_TIMESTAMP{NS} because it is a features that uses libc defined datatype and we include the kernel headers directly (so user has no opt-out). I consider most driver as opt-in, where users usually have to explicit include linux headers and they should be aware that if we want to use _TIME_BITS=64 they would need care to use libc-defined datatypes. But this is also error prone (and I would consider that drivers using libc-define datatypes are as well) and I see your point. I would prefer if we avoid extra 64-bit symbols, but if you think we would improve support in the future we can add as a conservative way. > >> Florian, in any case *currently* this patch does not need to use >> xsetsockopt. I can adapt if your set get merged first. > > Fine, go with xsetsockopt then. > > Thanks, > Florian >