From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0010f301.pphosted.com (mx0b-0010f301.pphosted.com [148.163.153.244]) by sourceware.org (Postfix) with ESMTPS id E88DA3858C5F for ; Fri, 4 Aug 2023 14:21:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E88DA3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=rice.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rice.edu Received: from pps.filterd (m0102860.ppops.net [127.0.0.1]) by mx0b-0010f301.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 374DMY9o018250 for ; Fri, 4 Aug 2023 09:21:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice.edu; h= mime-version:from:date:message-id:subject:to:content-type; s= ricemail; bh=cPqHbEbFQUzVZK7ukELtT7CrieT/bWYDBgYhCp5E9G4=; b=MB+ 99CzFLE10KWM01nFGAmQSjSy+UlOwAaKHld3nND01OF2FlGayvNrEYt2FR3cUTm1 pUiXlO0efiQVPXAdinavY720Hw7amDjkNu2KzM6/7lDAKiBVe9t7pRKdqcHngKfQ ChXH+2qU7Klyir8b/H8SSPuQFdlnOykByjz4KumMACK+3ErlsOlLuPgsTFcCD0ak Fcv7lELXlMPemOtihZVzuaV92l8WNvKrJKbS9DPub5oN9ojbNIMK2+AfKJ5YPPQ9 VlQMSV4s88CLNfw+nFduyIrsrGA2FaLJ2PjOmyvVq1q+jEwudcs38eOZP13BWUfW buvso7+RlY1Yw3HVokw== Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by mx0b-0010f301.pphosted.com (PPS) with ESMTPS id 3s75kn4a14-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 04 Aug 2023 09:21:22 -0500 (CDT) Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-3fe1cdf2024so13492825e9.3 for ; Fri, 04 Aug 2023 07:21:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691158880; x=1691763680; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cPqHbEbFQUzVZK7ukELtT7CrieT/bWYDBgYhCp5E9G4=; b=AGzxumSMNvBPdUy46NRQtsURmPIFKkosi8MSWb9t/BTfmnyJMAlpJRkU/KQfAHUABl WT310ySfNJDHxVz6REoeXkNaNXpQsCTcXfdVKMXMQqSXfwk2l6g5Mh+7CyvkXWuB08i5 J5ZjeymNs2rkzheQyQs47753kv2xFjKqtUGCUUxEbdaoHkFVYsCGu5jjN1eYBGxwSedu gFRYkjToxSntBtdw19NfJf/ISV4sM3D9Qodl4AbxAfxnwGGZsaAyZ8ZqcZhkpO92e0cA OIgAiJxpar1jWoH+kzra7uQ1ZzQ+1itMtK6rsEjRpNoeJpdPfS3PFfLMuK5y4/Pg571Q z1Pg== X-Gm-Message-State: AOJu0YwzgJHhX7JM9YPfcxwDkneUQnIVytOqRSqXMEHTTRqHCF3Qf6Gi A3PWi6uW8RUw6dm2R2G6bBD6zci9K5xszvXsJcau46RMdA2wAzQVQsdkdMp6fumF7KEIiDdx6HF OP7RSIvi1jGwgKdU7QgOrdcxX7u+ASQV4KMzRQjovkJTV1L5UFEk1ulO58qmEqCTc39tUxGtWm7 VX+kE= X-Received: by 2002:adf:ffc3:0:b0:317:5b99:d3d8 with SMTP id x3-20020adfffc3000000b003175b99d3d8mr1591541wrs.20.1691158880556; Fri, 04 Aug 2023 07:21:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFQHEyVKTy9NtdECU9SdoruhGV7qTenaqHqmOtsmKmLm2bL35/B0BXS+85uq2M0yuHaw09rqHEpUH/utAbbGIc= X-Received: by 2002:adf:ffc3:0:b0:317:5b99:d3d8 with SMTP id x3-20020adfffc3000000b003175b99d3d8mr1591521wrs.20.1691158880043; Fri, 04 Aug 2023 07:21:20 -0700 (PDT) MIME-Version: 1.0 From: Heather McIntyre Date: Fri, 4 Aug 2023 09:21:09 -0500 Message-ID: Subject: Deadlock from --enable-thread-safety To: elfutils-devel@sourceware.org Content-Type: multipart/alternative; boundary="0000000000004ddb2a0602199c37" X-Proofpoint-DLP: Gmail-Outbound X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-08-04_13,2023-08-03_01,2023-05-22_02 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000004ddb2a0602199c37 Content-Type: text/plain; charset="UTF-8" I've been making --enable-thread-safety (USE_LOCKS) more viable by fixing deadlocks throughout the libelf library. This has required minimal code changes so far. However, I've hit a snag where "__elf64_updatenull_wrlock" calls "elf64_getchdr," which leads to "elf64_getshdr." This sequence attempts to acquire a read lock under a write lock and fails. Similarly, "elf64_getchdr" calls "elf_getdata," which also tries and fails to implement a read lock. Unfortunately, fixing this particular deadlock requires more than minimal code changes. From what I understand, I may have a few options on how to fix this: 1) Create copies of the getchdr and elf_getdata functions, renaming them getchdr_wrlock and elf_getdata_wrlock. However, multiple copies of these functions could bloat the code, which may not be ideal. 2) Some type of write lock flag to indicate when a write lock is active. Either within the locking macro in eu-config.h or passed as an argument in the functions. Ultimately, I thought others may want to look into this to see if there might be options for a better solution. Here is the backtrace: Program received signal SIGABRT, Aborted. 0x00007ffff7837aff in raise () from /lib64/libc.so.6 #0 0x00007ffff7837aff in raise () from /lib64/libc.so.6 #1 0x00007ffff780aea5 in abort () from /lib64/libc.so.6 #2 0x00007ffff780ad79 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 #3 0x00007ffff78304c9 in __assert_perror_fail () from /lib64/libc.so.6 #4 0x00007ffff7fda554 in elf64_getshdr (scn=0x40fc20) at ../../libelf/elf32_getshdr.c:292 #5 0x00007ffff7fe9590 in elf64_getchdr (scn=0x40fc20) at ../../libelf/elf32_getchdr.c:45 #6 0x00007ffff7fdf690 in __elf64_updatenull_wrlock (elf=0x40d880, change_bop=0x7fffffffac60, shnum=30) at ../../libelf/elf32_updatenull.c:407 #7 0x00007ffff7fdd83d in elf_update (elf=0x40d880, cmd=ELF_C_WRITE) at ../../libelf/elf_update.c:211 #8 0x0000000000405d9e in process_file (fname=0x7fffffffbb96 "testfile-s390x-hash-both") at ../../src/elfcompress.c:1336 #9 0x0000000000406232 in main (argc=7, argv=0x7fffffffb768) at ../../src/elfcompress.c:1458 --0000000000004ddb2a0602199c37--