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: 1165522 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-105304-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=alibaba-inc.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="FMpZ+E+i"; dkim=pass (1024-bit key; unprotected) header.d=alibaba-inc.com header.i=@alibaba-inc.com header.b="pulukqwE"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46Zwrq2lfZz9sDB for ; Sat, 21 Sep 2019 13:23:06 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:cc:message-id:date :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=m4slZD/j/SBU+DQV4+x4MBMH32RBX/qP0SEdZkmlOqZNk8aZWNoSv sCeE3K6aRw9qljjjqQcTcQr6XNnzLtDRyxDJOaJocXs8NY9MPhO12VsUetB+LAip it0pR7WBJUTHwzf5jaoZTM2O/buyUKc5ssUCHhfBErVKJiW9ndwMkI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:subject:to:cc:message-id:date :mime-version:content-type:content-transfer-encoding; s=default; bh=e3a/rI6j74/Ynx5KXPzqrcSnSmA=; b=FMpZ+E+iTNLuN5cERhlfMY173GAZ UuPPXCKGyHzgDjTYJhr/EoS/cdnRK2aQDo3memM0jMqv+/sepIDGFZbkUXWyWg0h IQdkzMkUxE5n1P1JHvCcs1r7FsY9gZtHc2VKcxLI4PachjjGC7hS7UYn+XS6uPpd Nw1J/5CaT1KBTJ8= 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