From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 0BFFF3861810 for ; Wed, 30 Sep 2020 20:45:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0BFFF3861810 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08UKW5eE074172; Wed, 30 Sep 2020 16:45:22 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 33w0wnrkve-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 16:45:22 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08UKgQTB014627; Wed, 30 Sep 2020 20:45:21 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma04wdc.us.ibm.com with ESMTP id 33sw99gg8q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 20:45:21 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08UKjLn355837128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Sep 2020 20:45:21 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 06EA3AE05F; Wed, 30 Sep 2020 20:45:21 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6D1CDAE063; Wed, 30 Sep 2020 20:45:20 +0000 (GMT) Received: from [9.65.230.4] (unknown [9.65.230.4]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 30 Sep 2020 20:45:20 +0000 (GMT) Subject: Re: semtimedop, powerpc, time64 and older kernels To: Adhemerval Zanella , GNU C Library References: <6f370467-8d0a-bd3d-29b2-2fefef4e475f@linux.ibm.com> <490fc1e6-fd80-c5e5-0d0f-603fed44d4b6@linux.ibm.com> <7b907046-152a-d057-c01d-2d0a80f83931@linaro.org> From: Matheus Castanho Message-ID: <3e02f4be-92af-5b81-b207-e30308a68b80@linux.ibm.com> Date: Wed, 30 Sep 2020 17:45:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <7b907046-152a-d057-c01d-2d0a80f83931@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_10:2020-09-30, 2020-09-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 malwarescore=0 clxscore=1015 impostorscore=0 phishscore=0 mlxlogscore=999 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009300162 X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 30 Sep 2020 20:45:25 -0000 On 9/30/20 4:12 PM, Adhemerval Zanella wrote: > > > On 30/09/2020 15:29, Matheus Castanho wrote: >> Also, looks like my email client messed up the diff *sigh*. I'm sending >> a proper patch attached this time. >> >> -- >> Matheus Castanho >> > >> From 1c0a497a3f986bc6980581c9eab482ccf7bb190f Mon Sep 17 00:00:00 2001 >> From: Matheus Castanho >> Date: Wed, 30 Sep 2020 14:22:18 -0300 >> Subject: [PATCH] sysvipc: Fix semtimedop for Linux < 5.1 >> >> Kernels older than 5.1 will fail with ENOSYS when calling >> semtimedop_time64 syscall in __semtimedop_time64. Just like for >> !__ASSUME_TIME64_SYSCALLS, we should fallback to using the old mechanism >> in such cases. >> --- >> sysdeps/unix/sysv/linux/semtimedop.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/sysdeps/unix/sysv/linux/semtimedop.c b/sysdeps/unix/sysv/linux/semtimedop.c >> index a9ad922ee2..510fea1852 100644 >> --- a/sysdeps/unix/sysv/linux/semtimedop.c >> +++ b/sysdeps/unix/sysv/linux/semtimedop.c >> @@ -32,7 +32,7 @@ __semtimedop64 (int semid, struct sembuf *sops, size_t nsops, >> int r = INLINE_SYSCALL_CALL (semtimedop_time64, semid, sops, nsops, >> timeout); >> >> -#ifndef __ASSUME_TIME64_SYSCALLS >> +#if !(defined __ASSUME_TIME64_SYSCALLS) || __LINUX_KERNEL_VERSION < 0x050100 >> if (r == 0 || errno != ENOSYS) >> return r; >> >> -- >> 2.26.2 > > Thanks for catching it and although it fixes the regression, we have > kernel-features.h exactly to avoid using __LINUX_KERNEL_VERSION through the > implementations. Also this is sub-optimal since it forces semtimeopd issues > __NR_semtimeop and then __NR_ipc on powerpc64 and we have > __ASSUME_DIRECT_SYSVIPC_SYSCALLS exactly to avoid this strategy of handling > ENOSYS for newer syscalls and thus slowing it down the implementation on > older kernels (--enable-kernel exists exactly to get rid of this older kernel > support). > Thanks for the explanation. > I forgot that powerpc64 and s390x used the older multiplexed __NR_ipc and > kernel v5.1 decided to add proper __NR_semtimedop (and it was in fact handled > by 720e9541f5d919). I think a better fix is the one below, since it: > > 1. Issues __NR_semtimeop_time64 iff it is defined (32-bit architectures). > 2. Issues __NR_semtimeop otherwise iff glibc is configured for a kernel that > supports it (for powerpc64 it will only for --enable-kernel=5.1). > Otherwise it will use only 3. > 3. Issues __NR_ipc with IPCOP_semtimedop. > > For powerpc64 it will issue either __NR_ipc (default) or __NR_semtimeop > (--enable-kernel=5.1), while for powerpc it will use either > __NR_semtimeop_time64 and fallback to __NR_ipc or just issue > __NR_semtimeop_time64. Sounds good to me. That is indeed a better solution. Thanks! > > I am running some regressions before commit it. > > --- > > diff --git a/sysdeps/unix/sysv/linux/semtimedop.c b/sysdeps/unix/sysv/linux/semtimedop.c > index a9ad922ee2..29647f8ccd 100644 > --- a/sysdeps/unix/sysv/linux/semtimedop.c > +++ b/sysdeps/unix/sysv/linux/semtimedop.c > @@ -26,11 +26,15 @@ int > __semtimedop64 (int semid, struct sembuf *sops, size_t nsops, > const struct __timespec64 *timeout) > { > -#ifndef __NR_semtimedop_time64 > -# define __NR_semtimedop_time64 __NR_semtimedop > + int r; > +#if defined __NR_semtimedop_time64 > + r = INLINE_SYSCALL_CALL (semtimedop_time64, semid, sops, nsops, timeout); > +#elif defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS && defined __NR_semtimedop > + r = INLINE_SYSCALL_CALL (semtimedop, semid, sops, nsops, timeout); > +#else > + r = INLINE_SYSCALL_CALL (ipc, IPCOP_semtimedop, semid, > + SEMTIMEDOP_IPC_ARGS (nsops, sops, timeout)); > #endif > - int r = INLINE_SYSCALL_CALL (semtimedop_time64, semid, sops, nsops, > - timeout); > > #ifndef __ASSUME_TIME64_SYSCALLS > if (r == 0 || errno != ENOSYS) > The change looks good and fixes the issue. Tested on ppc64le. Reviewed-by: Matheus Castanho -- Matheus Castanho