From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from impout004.msg.chrl.nc.charter.net (impout004aa.msg.chrl.nc.charter.net [47.43.20.28]) by sourceware.org (Postfix) with ESMTPS id 11CD5386F436; Fri, 12 Mar 2021 01:35:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 11CD5386F436 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=charter.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jvdelisle@charter.net Received: from [192.168.1.9] ([96.41.221.129]) by cmsmtp with ESMTPA id KWiRlm25Zxxx6KWiSlHHjn; Fri, 12 Mar 2021 01:35:49 +0000 Authentication-Results: charter.net; none X-Authority-Analysis: v=2.3 cv=TK7xtGta c=1 sm=1 tr=0 a=07pILqX15KmGv9ZXTMmBNA==:117 a=07pILqX15KmGv9ZXTMmBNA==:17 a=IkcTkHD0fZMA:10 a=vJAELTtXDI9SHJiLU54A:9 a=QEXdDO2ut3YA:10 Subject: Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529] To: Tobias Burnus , gcc-patches , fortran , mscfd@gmx.net References: <9b6fa121-a5ea-4d2c-9924-fcdfe7d6d560@net-b.de> From: Jerry DeLisle Message-ID: <14a334fb-c586-25d5-93b5-dbe2fd90971e@charter.net> Date: Thu, 11 Mar 2021 17:35:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <9b6fa121-a5ea-4d2c-9924-fcdfe7d6d560@net-b.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfJF/VnZGE4wzLBktdYVyzVz58c6f1i8AXY8GEGaY0iqcwguB+bgGutK0GXlQg//SB77yBrE40FPBhd73h5WncU9LTnd3oYNXtevJ23uvC3RUgnvJbbeG ySfz59pu9O+Vp6KrKlTs75PcoaYVA/iOdrO4cYUn90MgIxEpMW7FcZUeU77UKOxu+u0jgZFigG0Qn9BE+7XgWXY34zU1/2pHplBCexjkVtXsj90McZioKcan 2f8Tl5+4r4DaBux1fSrYmQ== X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FROM, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 01:35:51 -0000 Looks good Tobias, OK, Odd about that line in set_internal_unit. Probably leftover from a copy/paste. I see in comment #5 of the PR that you mentioned trying the assert to make sure it is useless code. Thanks for the patch, Jerry On 3/11/21 2:38 AM, Tobias Burnus wrote: > Revised version – the previous had a lock inversion, which could lead > to a deadlock, found by -fsanitize=thread. See transfer.c for the > changes. > > OK? > > Tobias > > On 11.03.21 10:42, Tobias Burnus wrote: >> Hi all, >> >> as found by Martin (thanks!) there is a race for newunit_free. >> While that call is within the unitlock for the calls in io/unit.c, >> the call in transfer.c did not use locks. >> >> Additionally, >>       unit = get_gfc_unit (dtp->common.unit, do_create); >>       set_internal_unit (dtp, unit, kind); >> gets first the unit (with proper locking when using the unit number >> dtp->common.unit) but then in set_internal_unit it re-sets the >> unit number to the same number without locking. That causes >> race warnings and if the assignment is not atomic it is a true race. >> >> OK for mainline? What about GCC 10? >> >> As Martin notes in the email thread and in the PR there are more >> race warnings (and likely true race issues). >> >> Tobias >>