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-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id CE7F41F4B4 for ; Mon, 19 Oct 2020 12:48:24 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B56C738708FD; Mon, 19 Oct 2020 12:48:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B56C738708FD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603111703; bh=IpZG52S/msiZ07a6fp587KFB5/sKpQDN+rCKqFrYV/Y=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=qEn8V0EYHuYUI2mBWGBPS0iB9OEyGDa6By0xmds3zoxoax2pPIZ3xxa1xL8Yg/91c NtplSuB0s0I9Zsm8dCz9Jt7933gVtmVxYRzPyAQimmoa5AkEewA+P/r8HSsw6relvQ mDMfKx3N0Ne7TGJfjLIDubl2UANExnMl3ixDH3js= Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 9CDCF386F81A for ; Mon, 19 Oct 2020 12:48:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9CDCF386F81A Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JCXWlX050266; Mon, 19 Oct 2020 08:48:17 -0400 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 349avdrj53-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 08:48:17 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 09JCRVBL003902; Mon, 19 Oct 2020 12:48:15 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma06ams.nl.ibm.com with ESMTP id 347qvha3xv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 12:48:15 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 09JCmCRj8126748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Oct 2020 12:48:12 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CB43F42041; Mon, 19 Oct 2020 12:48:12 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9ADA642047; Mon, 19 Oct 2020 12:48:12 +0000 (GMT) Received: from oc4452167425.ibm.com (unknown [9.145.153.58]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 19 Oct 2020 12:48:12 +0000 (GMT) Subject: Re: [PATCH v2] y2038: nptl: Convert pthread_mutex_{clock|timed}lock to support 64 bit To: Lukasz Majewski References: <20201008155617.19032-1-lukma@denx.de> <20201019135937.176650ab@jawa> Message-ID: <78fd90fb-f852-fcc2-303a-3320eff77cf6@linux.ibm.com> Date: Mon, 19 Oct 2020 14:48:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201019135937.176650ab@jawa> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_05:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0 adultscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190091 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: , From: Stefan Liebler via Libc-alpha Reply-To: Stefan Liebler Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 10/19/20 1:59 PM, Lukasz Majewski wrote: > Hi Stefan, > >> Hi Lukasz, >> >> With this commit, the testcase nptl/tst-robust10 times out on s390 >> (31bit, big-endian). >> >> For me it seems that one futex call was not adjusted while converting >> abstime of __pthread_mutex_clocklock_common function from struct >> timespec to struct __timespec64: >> ┌──../nptl/pthread_mutex_timedlock.c >> │ 270 /* Block using the futex. */ >> │ >271 int err = lll_futex_clock_wait_bitset >> (&mutex->__data.__lock, > > Yes. You are right. The lll_futex_clock_wait_bitset shall be converted > as well... I must have overlooked it, sorry. > >> │ 272 oldval, clockid, abstime, >> │ 273 PTHREAD_ROBUST_MUTEX_PSHARED (mutex)); >> (gdb) where >> #0 0x7dfb9948 in __pthread_mutex_clocklock_common >> (mutex=mutex@entry=0x406144 , clockid=clockid@entry=0, >> abstime=abstime@entry=0x7ddf9290) >> at ../nptl/pthread_mutex_timedlock.c:271 >> #1 0x7dfb9c12 in __GI___pthread_mutex_timedlock64 >> (abstime=0x7ddf9290, mutex=0x406144 ) at >> ../nptl/pthread_mutex_timedlock.c:632 #2 __pthread_mutex_timedlock >> (mutex=mutex@entry=0x406144 , >> abstime=abstime@entry=0x7ddf930c) at >> ../nptl/pthread_mutex_timedlock.c:644 #3 0x004020bc in thr >> (arg=) at ../sysdeps/pthread/tst-robust10.c:33 #4 >> 0x7dfb6a06 in start_thread (arg=0x7ddf9b00) at pthread_create.c:463 >> #5 0x7df08434 in thread_start () at >> ../sysdeps/unix/sysv/linux/s390/s390-32/clone.S:64 >> >> >> Thus the futex syscall interprets the struct __timespec64 as struct >> timespec and the result is an infinite loop: >> (gdb) p abstime >> $6 = (const struct __timespec64 *) 0x7ddf9290 >> >> (gdb) p/x *abstime >> $9 = {tv_sec = 0x5f8d597f, tv_nsec = 0xd79f074} >> >> (gdb) p/x *((struct timespec *) abstime) >> $10 = {tv_sec = 0x0, tv_nsec = 0x5f8d597f} >> >> (gdb) x/4xw abstime >> 0x7ddf9290: 0x00000000 0x5f8d597f 0x00000000 >> 0x0d79f074 >> >> >> >> strace output: >> 10:59:58.611688 futex(0x406144, >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0, >> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid >> argument) <0.000006> 10:59:58.611707 futex(0x406144, >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0, >> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid >> argument) <0.000006> 10:59:58.611724 futex(0x406144, >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2148981693, {tv_sec=0, >> tv_nsec=1603098008}, FUTEX_BITSET_MATCH_ANY) = -1 EINVAL (Invalid >> argument) <0.000006> >> >> >> This is also observable on x86 (32bit). But there only tv_nsec is 0 >> and thus it does not result in an infinite loop: >> 11:22:30.348352 futex(0x804f0f4, >> FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2147913074, >> {tv_sec=1603099351, tv_nsec=0}, FUTEX_BITSET_MATCH_ANY) = -1 >> ETIMEDOUT (Connection timed out) <0.652043> >> >> Can you please have a look? >> > > I'm going to prepare and sent fixes ASAP. Big thanks for spotting it. Thanks. Let me know, then I can run a test on s390 if you want. Bye, Stefan