From owner-freebsd-hackers@freebsd.org  Fri Aug 24 19:23:27 2018
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52DDF1092261
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Fri, 24 Aug 2018 19:23:27 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 9703B7382B
 for <freebsd-hackers@freebsd.org>; Fri, 24 Aug 2018 19:23:26 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
 by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w7OJNF3K076045
 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Fri, 24 Aug 2018 22:23:18 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7OJNF3K076045
Received: (from kostik@localhost)
 by tom.home (8.15.2/8.15.2/Submit) id w7OJNFs3076044;
 Fri, 24 Aug 2018 22:23:15 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Fri, 24 Aug 2018 22:23:15 +0300
From: Konstantin Belousov <kostikbel@gmail.com>
To: Eric van Gyzen <eric@vangyzen.net>
Cc: Gleb Popov <6yearold@gmail.com>,
 freebsd-hackers <freebsd-hackers@freebsd.org>
Subject: Re: Strange hang when calling signal()
Message-ID: <20180824192315.GF2340@kib.kiev.ua>
References: <CALH631mtb1Z-4v4+UuzCx0tX0Zt5LfoQR9+iags-nL7MRUhGLA@mail.gmail.com>
 <20180824185328.GE2340@kib.kiev.ua>
 <4e555da7-9384-0f22-3ef9-8b3661a48529@vangyzen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4e555da7-9384-0f22-3ef9-8b3661a48529@vangyzen.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 19:23:27 -0000

On Fri, Aug 24, 2018 at 02:10:36PM -0500, Eric van Gyzen wrote:
> On 8/24/18 1:53 PM, Konstantin Belousov wrote:
> > Since then, we started locking most of that locks in parent around fork(2),
> > all the code in lib/libthr/thread/thr_fork.c.  In particular, we lock rtld,
> > malloc, and disable cancellation around fork.  So if your program used fork(2)
> > but ended with the broken rtld it is worrying.
> > 
> > On the other hand, we do not do that for vfork(2).  So yes, the minimal
> 
> We also do not do that for rfork(2).  I think we should, but I have not 
> done any research into it.

I do not see how would it be correct to do that locking for vfork(2) because
the address space is shared between parent and child.  For the similar reason,
sometimes rfork(2) also leaves the address space shared and then we have
the problem.

In essence, rfork(2) and vfork(2) do not mix with pthreads, and if you do,
you should know well what you do.