Date: Fri, 24 Aug 2018 14:38:46 -0500 From: Eric van Gyzen <eric@vangyzen.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Strange hang when calling signal() Message-ID: <d6307082-b340-a11a-b531-85d9f1ff205d@vangyzen.net> In-Reply-To: <20180824192315.GF2340@kib.kiev.ua> References: <CALH631mtb1Z-4v4%2BUuzCx0tX0Zt5LfoQR9%2Biags-nL7MRUhGLA@mail.gmail.com> <20180824185328.GE2340@kib.kiev.ua> <4e555da7-9384-0f22-3ef9-8b3661a48529@vangyzen.net> <20180824192315.GF2340@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/24/18 2:23 PM, Konstantin Belousov wrote: > 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. I wasn't suggesting that we do it for vfork(2). I was only suggesting that we do it for rfork(2), and obviously only if !RFMEM (and certain other flag conditions). Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d6307082-b340-a11a-b531-85d9f1ff205d>