Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Oct 2007 17:54:16 +0000 (UTC)
From:      Julian Elischer <julian@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/kern kern_fork.c
Message-ID:  <200710231754.l9NHsGLH090312@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
julian      2007-10-23 17:54:16 UTC

  FreeBSD src repository

  Modified files:
    sys/kern             kern_fork.c 
  Log:
  Take out the single-threading code in fork.
  After discussions with jeff, alc, (various Ironport people), david Xu,
  and mostly Alfred (who found the problem) it has been demonstrated that this
  is not needed for our implementations of threads and represents a real
  (as in we've seen it happen a lot) deadlock danger.
  
  Several points:
   Since forking multiple threads is not allowed, and posix states that
   any mutexes owned by othre threads wilol be owned in the child by
   phantom threads, and therads shouldn't ba accessing shared structures without
   protection, It can be proved that if this leads to the child process accessing
   inconsistent data, it's a programming error.
  
   The mode of thread_single() being used in fork() is the wrong one.
   It is using SINGLE_NO_EXIT when it should be using SINGLE_BOUNDARY.
  
   Even if this we used, System processes have no need to do it as they have
   no userland to get inconsistent.
  
    This commmit first fixes the above bugs to get tehm correct in CVS.
    then removes them with #ifdef.
    This is so that history contains the corrected version should it
    be needed in the future.
    This code may be needed if we implement the forkall() syscall from
    Solaris. It may be needed for other non-posix thread libraries
    at some time in the future, so let the code sit for a short while
    while I do some work on it anyhow.
  
  This removes a reproducible lockup in NFS.
  It may be argued that maybe doing a fork while holding a vnode lock may
  not be the best idea in th efirst place but it shouldn't cause a deadlock.
  The removal has been running under soak test for several days now.
  
  This removal should be seriously considered for 7.0 and RELENG_6.
  
  Note. There is code in the core-dumping code that may have a similar problem
  with coredumping threaded processes
  
  MFC After: 4 days
  
  Revision  Changes    Path
  1.284     +15 -5     src/sys/kern/kern_fork.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710231754.l9NHsGLH090312>