From nobody@FreeBSD.org  Wed Sep 18 19:23:35 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id A518837B401
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 18 Sep 2002 19:23:35 -0700 (PDT)
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 674F543E6E
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 18 Sep 2002 19:23:35 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.6/8.12.6) with ESMTP id g8J2NV7R061738
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 18 Sep 2002 19:23:31 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.6/8.12.6/Submit) id g8J2NVDO061737;
	Wed, 18 Sep 2002 19:23:31 -0700 (PDT)
Message-Id: <200209190223.g8J2NVDO061737@www.freebsd.org>
Date: Wed, 18 Sep 2002 19:23:31 -0700 (PDT)
From: pqf <pqf@163.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: fd 0,1,2 should not be set to nonblock in _thread_fd_table_init()
X-Send-Pr-Version: www-1.0

>Number:         42943
>Category:       misc
>Synopsis:       fd 0,1,2 should not be set to nonblock in _thread_fd_table_init()
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 18 19:30:01 PDT 2002
>Closed-Date:    Sat May 10 14:41:21 PDT 2003
>Last-Modified:  Sat May 10 14:41:21 PDT 2003
>Originator:     pqf
>Release:        FreeBSD bsd 4.6.2-RELEASE
>Organization:
www.tebie.com
>Environment:
FreeBSD bsd 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 14 21:23:26 GMT 2002     murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC  i386
>Description:
in uthread_fd.c line 141, it set fd 0, 1, 2 to nonblock mode, and so the fd 0, 1, 2 in kernel is nonblock mode, but the mode of them in uthread level MAY be blocking
normally, it's ok to do so, but think about the following condition:
parend process call dup2() to make fd 0 be a unix domain socket
parent process fork() muti-thread(pthread) child process
child process set fd 0 to nonblock in _thread_fd_table_init()
fd 0 is shared between parent process and child process, so the parent process's fd 0 is now nonblock, but the parent process DO NOT know what happen because it DID NOT do anything to fd 0...

>How-To-Repeat:
      
>Fix:
comment line 140 to line 143 in uthread_fd.c
>Release-Note:
>Audit-Trail:

From: Gregory Bond <gnb@itga.com.au>
To: pqf <pqf@163.net>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: misc/42943: fd 0,1,2 should not be set to nonblock in _thread_fd_table_init() 
Date: Thu, 19 Sep 2002 14:40:34 +1000

 > parend process call dup2() to make fd 0 be a unix domain socket
 > parent process fork() muti-thread(pthread) child process
 > child process set fd 0 to nonblock in _thread_fd_table_init()
 > fd 0 is shared between parent process and child process, so the parent proces
 > s's fd 0 is now nonblock, but the parent process DO NOT know what happen beca
 > use it DID NOT do anything to fd 0...
 
 I would argue this is a bug in the (parent) program - if you are going to 
 share file descriptors, you'd better make sure you understand what the other 
 program is going to do to them!
 
 

From: Peter Pentchev <roam@ringlet.net>
To: Gregory Bond <gnb@itga.com.au>
Cc: bug-followup@FreeBSD.org
Subject: Re: misc/42943: fd 0,1,2 should not be set to nonblock in _thread_fd_table_init()
Date: Thu, 19 Sep 2002 11:07:19 +0300

 On Wed, Sep 18, 2002 at 09:50:03PM -0700, Gregory Bond wrote:
 [the PR submitter, pqf, wrote:]
 >  > parend process call dup2() to make fd 0 be a unix domain socket
 >  > parent process fork() muti-thread(pthread) child process
 >  > child process set fd 0 to nonblock in _thread_fd_table_init()
 >  > fd 0 is shared between parent process and child process, so the parent proces
 >  > s's fd 0 is now nonblock, but the parent process DO NOT know what happen beca
 >  > use it DID NOT do anything to fd 0...
 >  
 >  I would argue this is a bug in the (parent) program - if you are going to 
 >  share file descriptors, you'd better make sure you understand what the other 
 >  program is going to do to them!
 
 I fully agree.  If the thread library did not set fd's 0, 1, 2 to
 non-blocking mode, then any attempt of a thread to read/write to them
 would, well, block - blocking the whole application along the way.
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 because I didn't think of a good beginning of it.

From: pan qingfeng <panqingfengtebie@yahoo.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: misc/42943: fd 0,1,2 should not be set to nonblock in _thread_fd_table_init()
Date: Thu, 26 Sep 2002 22:02:11 -0700 (PDT)

 --0-818482201-1033102931=:34032
 Content-Type: text/plain; charset=us-ascii
 
 Buf BOTH of the parent process and child process DO NOT call fcntl() to change the fd state,
 after praent fork() and exec() the muti-thread process, the parent process found fd 0 is now
 nonblock...
 So, can i assume that: After fork() and exec() a muti-thread process, than you have to 
 check your fd 0, fd 1, fd 2 for blocking in parent process? I don't think it's a standard
 behavior of exec(), all other pthread lib do not do this.
 I think the child process should use the file state what they inherit but not force to set it to be nonblock,
 at least this  behavior including in the doc of exec()...
 
 
 ---------------------------------
 Do you Yahoo!?
 New DSL Internet Access from SBC & Yahoo!
 --0-818482201-1033102931=:34032
 Content-Type: text/html; charset=us-ascii
 
 Buf BOTH of the parent process and child process DO NOT call fcntl() to change the fd state,<BR>after praent fork() and exec() the muti-thread process, the parent process found fd 0 is now<BR>nonblock...<BR>So, can i assume that: After fork() and exec() a muti-thread process, than you have to <BR>check your fd 0, fd 1, fd 2 for blocking in parent process? I don't think it's a standard<BR>behavior of exec(), all other pthread lib do not do this.<BR>I think the child process should use the file state what th ey inherit but not force to set it to be nonblock,<BR>at least this&nbsp; behavior including in the doc of exec()...<p><br><hr size=1>Do you Yahoo!?<br>
 New <a href="http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/">DSL Internet Access</a> from SBC & Yahoo!</a>
 --0-818482201-1033102931=:34032--

From: "Dorr H. Clark" <dclark@applmath.scu.edu>
To: freebsd-gnats-submit@FreeBSD.org, pqf@163.net
Cc:  
Subject: see 41331 Re: misc/42943: fd 0,1,2 should not be set to nonblock in 
 _thread_fd_table_init()
Date: Mon, 05 May 2003 20:35:01 -0700

 42943 is a duplicate of 41331, or at best an extended symptom.
 
 Please see that PR for more detailed discussion.
 
 Rashmi Venkatesh, engineer
 Dorr H. Clark, advisor
 COEN 284 - Operating Systems Case Study 
 Santa Clara University, 
 Santa Clara CA.
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Sat May 10 14:40:38 PDT 2003 
State-Changed-Why:  
Duplicate of misc/41331. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=42943 
>Unformatted:
