From patchwork Sat Sep 21 03:21:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?UTF-8?B?6LCi5a6c55SfKOavheaZnyk=?= X-Patchwork-Id: 34630 Received: (qmail 72922 invoked by alias); 21 Sep 2019 03:22:59 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 72907 invoked by uid 89); 21 Sep 2019 03:22:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FROM_EXCESS_BASE64, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 spammy=H*Ad:U*rth, H*UA:Macintosh, HContent-Transfer-Encoding:8bit, H*u:Macintosh X-HELO: out0-132.mail.aliyun.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1569036174; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type; bh=RZ62pyNsVsIUep+dCnePhIEnlmL64XysBqq+QXWnA24=; b=pulukqwE9pddiMVfBgr7TsIG+/8CuKuxHM+l3q8LdZdzVLeRi05YQVqWYq5ZQikJgfqkHhafLO5zCwkxhsMeneTCP/70J7Rupj7s2085a2UhUEr9rCPhnsnHa4MdQe9eNj2DEg79DGlR8voELIKlid03IcdrxwkRSPcYxt7Ncyo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R251e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03291; MF=yisheng.xys@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_---.FYemE3S_1569036173; From: "=?UTF-8?B?6LCi5a6c55SfKOavheaZnyk=?=" Subject: [PATCH RFC] libio: Fix deadlock between freopen and fclose [BZ #24963] To: libc-alpha@sourceware.org Cc: , , "=?UTF-8?B?5a6L5Li55bOwKOeFnOaYiik=?=" Message-ID: Date: Sat, 21 Sep 2019 11:21:28 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 we find a deadlock between fclose and freopen as following: CPU0                                          CPU1 freopen                                       fclose   ->_IO_acquire_lock (fp)                         ->_IO_un_link   ->_IO_file_close_it                              ->_IO_lock_lock(list_all_lock)     ->_IO_un_link       ->_IO_lock_lock (list_all_lock)<-wait here                                                    ->_IO_flockfile((_IO_FILE *) fp); <-- wait here As Carlos pointed that this maybe the bug of in _IO_new_fclose, which can be fixed by locking fp first, then with fp acquired lock the whole list. Signed-off-by: Yisheng Xie ---  libio/iofclose.c | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) -- 2.23.0 diff --git a/libio/iofclose.c b/libio/iofclose.c index 398b86d597..fe262cf6aa 100644 --- a/libio/iofclose.c +++ b/libio/iofclose.c @@ -44,11 +44,11 @@ _IO_new_fclose (FILE *fp)      return _IO_old_fclose (fp);  #endif +  _IO_acquire_lock (fp);    /* First unlink the stream.  */    if (fp->_flags & _IO_IS_FILEBUF)      _IO_un_link ((struct _IO_FILE_plus *) fp); -  _IO_acquire_lock (fp);    if (fp->_flags & _IO_IS_FILEBUF)      status = _IO_file_close_it (fp);    else