From owner-freebsd-hackers  Fri Nov 21 17:58:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA03850
          for hackers-outgoing; Fri, 21 Nov 1997 17:58:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03839
          for <freebsd-hackers@FreeBSD.ORG>; Fri, 21 Nov 1997 17:58:14 -0800 (PST)
          (envelope-from alex@zen.nash.org)
Received: (from alex@localhost)
	by zen.nash.org (8.8.8/8.8.7) id TAA05968;
	Fri, 21 Nov 1997 19:54:54 -0600 (CST)
	(envelope-from alex)
Message-Id: <199711220154.TAA05968@zen.nash.org>
Date: Fri, 21 Nov 1997 19:54:53 -0600 (CST)
From: nash@mcs.net
Reply-To: nash@mcs.com
Subject: Re: malloc() problems in children after using rfork()
To: julian@whistle.com
cc: cbray@best.com, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <34762398.1CFBAE39@whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On 21 Nov, Julian Elischer wrote:
>> The only locking malloc() performs is pthread_mutex_lock/unlock in the
>> libc_r version.  The non-threaded version provides no locking at all.
[...]
> I just saw the other email
> 
> he's using 2.2.5
> rfmem don't work in 2.2.x.
> well it DOES but it only shares EXISTING memory.
> new allocations are not shared..

and in a subsequent email...

> New allocations from the kernel (done after the rfork)
> are not shared..
> this was fixed in -current but I'm pretty sure john has not back-ported
> it.

Unless I'm missing something, even if the fix was brought into -stable
it still won't allow multiple rforked(RFMEM|RFPROC) processes to malloc
out of a shared data segment (without locking, of course).

Alex