From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7B1AD1F463 for ; Wed, 27 Nov 2019 19:28:08 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=a3vI99PZHm0mUkGY s8LtndnvEV8d+WgphoXRtMRYFhDu+z0qEphnxvPKvXyAAmFpMAFUBwHtcw18lWty N322ngMuKFBTIfZlC44UfHlwWwjFTB/yY6Mf+cKxslKCXsAVpWtyAGuQtlmf+neI nYf/qyhXWFq+8BSDQjk6lfHtsh4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=0uWy/xkSf8lHXwUEB6NKNg frmng=; b=bU0zGqSNzmpT1ul2d7NXvPi5wTvSj4aJ2V0/qPPHpcmV8vsxULHvB+ VirQ8sbdjrs1QfiPXlIu7ZBykPt2yEU5Nw59loWoiixYCNRBIL8bKX9IdUpK/ZV6 kT45LDdL4r8IFf3lHeXv/FbqjG2VbllsNfdOJRhCTlM8jqdGO2l7g= Received: (qmail 3222 invoked by alias); 27 Nov 2019 19:28:06 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 2852 invoked by uid 89); 27 Nov 2019 19:28:05 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH 1/2] linux: clock_settime: Remove check for nanoseconds validity To: Lukasz Majewski , Joseph Myers Cc: Alistair Francis , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , Florian Weimer , Zack Weinberg , Carlos O'Donell References: <20191108153344.10949-1-lukma@denx.de> <20191111164531.1411bd48@jawa> <20191127180436.0e83a744@jawa> From: Paul Eggert Message-ID: <06446e8b-0226-1c57-1c7b-a5c7d6b7bd20@cs.ucla.edu> Date: Wed, 27 Nov 2019 11:27:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191127180436.0e83a744@jawa> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/27/19 9:04 AM, Lukasz Majewski wrote: >> a/sysdeps/unix/sysv/linux/clock_settime.c +++ >> b/sysdeps/unix/sysv/linux/clock_settime.c @@ -25,13 +25,6 @@ >> int >> __clock_settime64 (clockid_t clock_id, const struct __timespec64 >> *tp) { >> - /* Make sure the time cvalue is OK. */ >> - if (! valid_nanoseconds (tp->tv_nsec)) >> - { >> - __set_errno (EINVAL); >> - return -1; >> - } >> - > I'm just wondering if this patch is OK, as with other patches, which > convert time to use 64 bit syscalls we do rely on Linux kernel to > check the nanoseconds (and return proper error). Suppose tp->tv_sec == 1 && tp->tv_nsec == -1 && !defined __ASSUME_TIME64_SYSCALLS && !defined __NR_clock_settime64. Then the current code will fail with errno == EINVAL, but with the proposed patch the code will succeed and set the time to 1 second after the Epoch. Code should always check for valid nanoseconds before calling valid_timespec64_to_timespec with possibly-invalid input. In this function, the check can be done at about the same time as the in_time_t_range check; that'd be better than what the current code does.