Message ID | f6757145-6d1a-e1e5-6b2b-9f7b7e65e26b@alibaba-inc.com |
---|---|
State | Dropped |
Headers |
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: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> 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=?=" <yisheng.xys@alibaba-inc.com> Subject: [PATCH RFC] libio: Fix deadlock between freopen and fclose [BZ #24963] To: libc-alpha@sourceware.org Cc: <rth@tamu.ed>, <carlos@redhat.com>, "=?UTF-8?B?5a6L5Li55bOwKOeFnOaYiik=?=" <danfeng.sdf@alibaba-inc.com> Message-ID: <f6757145-6d1a-e1e5-6b2b-9f7b7e65e26b@alibaba-inc.com> 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit |
Commit Message
=?UTF-8?B?6LCi5a6c55SfKOavheaZnyk=?=
Sept. 21, 2019, 3:21 a.m. UTC
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 <yisheng.xys@alibaba-inc.com>
---
libio/iofclose.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.23.0
Comments
On 21/09/2019 04:21, 谢宜生(毅晟) wrote: > 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. if we want to keep freopen as is then an fp cannot be locked after list_all_lock is held, if another thread might freopen(fp). this affects more than just fclose, e.g. fflush(NULL) would have the same lock ordering (first locks list_all_lock, then locks each fp) this tells me that a different fix is needed, either way there should be a bug report about it in bugzilla (and the id referenced in the changelog of a patch submission assuming you have the fsf copyright assignment sorted out). > > Signed-off-by: Yisheng Xie <yisheng.xys@alibaba-inc.com> > --- > libio/iofclose.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > 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 > -- > 2.23.0 >
On 23/09/2019 11:05, Szabolcs Nagy wrote: > either way there should be a bug report about > it in bugzilla (and the id referenced in the sorry, missed the bugzilla id in the subject, i commented on the bug now.
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