From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id A0E9C3842AD6 for ; Thu, 30 Jun 2022 11:11:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0E9C3842AD6 Received: by mail-oi1-x22e.google.com with SMTP id w193so25544299oie.5 for ; Thu, 30 Jun 2022 04:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5YPmYNutdN/H7DlcqID2jmfn5JOGPHPIESED64VSL8g=; b=I2Kf4MVjuSW4BVsUb0iGfQbMxyZdNdAUf4NZcbcDJW8cZguNNw+cpUEFNVHQkbOosQ Vh4CuyV18A2G6lpCV0N3mnFLX+zMme9+SHU+4kiiguI2IwrJzHMqmeSp3Ecf0sspq2ew T3FbGrtz+hfxB2bHtcpCDl/KXOYcaFtIj4/a3407/PHsb7cB+acn4PkZ4Hr9bKO6/+mV 54tEOzP5LwOCHx//YXZuQFIIycSNvva6CoJXYZWEvwHsG8AgUB7OrLrpaVsoVpzVIk48 wVYMKrouAmD3p0Xn6Yk5p1QpRMOHQBoFN9xFQTBNx8Gt2IIhzDIvhcSlve+P6sWN6p0t 2OtQ== X-Gm-Message-State: AJIora80NsZTw65+uoYig7Oucj8zVzsSYxB3tQ9hBGXPs/rdmg5vvW3z +iG/EI0PC+3pZUU9wW94W4PWzA== X-Google-Smtp-Source: AGRyM1sVL3F6hABMIY8d/mXt9I1uQ91S49aZ5XCF9xijTMZ1M51yPDSsCVlsOGe4yk2n8jEVE/RldQ== X-Received: by 2002:a05:6808:1414:b0:335:7992:263a with SMTP id w20-20020a056808141400b003357992263amr6066740oiv.9.1656587459942; Thu, 30 Jun 2022 04:10:59 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7cb:fef6:c4a4:5cf:6a9a:8440]) by smtp.gmail.com with ESMTPSA id j24-20020a4a7518000000b0041b89126eacsm10727156ooc.14.2022.06.30.04.10.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2022 04:10:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Suspected bug in mq_timedreceive From: Adhemerval Zanella In-Reply-To: <000f01d88c4b$df941790$9ebc46b0$@gmail.com> Date: Thu, 30 Jun 2022 08:10:54 -0300 Cc: libc-help@sourceware.org, libc-help-info@sourceware.org, libc-alpha@sourceware.org, libc-alpha-info@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <000f01d88c4b$df941790$9ebc46b0$@gmail.com> To: sundeep.kokkonda@gmail.com X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 11:11:02 -0000 > On 30 Jun 2022, at 03:37, sundeep.kokkonda--- via Libc-help = wrote: >=20 > Hello, >=20 >=20 >=20 > The mq_timedreceive code in > glibc-2.33/sysdeps/unix/sysv/linux/mq_timedreceive.c does this: >=20 >=20 >=20 > ssize_t >=20 > _mq_timedreceive_time64 (mqd_t mqdes, char *_restrict msg_ptr, size_t > msg_len, >=20 > unsigned int *__restrict msg_prio, >=20 > const struct _timespec64 *_restrict = abs_timeout) >=20 > { >=20 > #ifndef __NR_mq_timedreceive_time64 >=20 > #define __NR_mq_timedreceive_time64 __NR_mq_timedreceive >=20 > #endif >=20 > int ret =3D SYSCALL_CANCEL (mq_timedreceive_time64, mqdes, msg_ptr, = msg_len, >=20 > msg_prio, abs_timeout); >=20 > #ifndef __ASSUME_TIME64_SYSCALLS >=20 > if (ret =3D=3D 0 || errno !=3D ENOSYS) >=20 > return ret; >=20 >=20 >=20 > struct timespec ts32; >=20 > if (abs_timeout !=3D NULL) >=20 > { >=20 > if (! in_time_t_range (abs_timeout->tv_sec)) >=20 >=20 >=20 >=20 >=20 > { __set_errno (EOVERFLOW); return -1; } >=20 > ts32 =3D valid_timespec64_to_timespec (*abs_timeout); >=20 > } >=20 >=20 >=20 > ret =3D SYSCALL_CANCEL (mq_timedreceive, mqdes, msg_ptr, msg_len, = msg_prio, >=20 > abs_timeout !=3D NULL ? &ts32 : NULL); >=20 > #endif >=20 >=20 >=20 > return ret; >=20 > } >=20 >=20 >=20 > This test is wrong: >=20 >=20 >=20 > if (ret =3D=3D 0 || errno !=3D ENOSYS) >=20 > return ret; >=20 >=20 >=20 > That test would be correct if mq_timedreceive returned 0 on success, = as is > the case for mq_timedsend. However, mq_timedreceive actually returns = the > number of bytes read, so the correct test is: >=20 >=20 >=20 > If (ret >=3D 0 || errno !=3D ENOSYS) >=20 > return ret; Yeah, this is incorrect. I will open a bug an fix it on all affected = releases. At least for 2.36 the time64 code path is only used if the target date = can not be fit in 32-bit time_t.=