From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13456 invoked by alias); 29 Apr 2012 15:34:48 -0000 Received: (qmail 13314 invoked by uid 22791); 29 Apr 2012 15:34:47 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BF X-Spam-Check-By: sourceware.org Received: from mail-lb0-f169.google.com (HELO mail-lb0-f169.google.com) (209.85.217.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Apr 2012 15:34:34 +0000 Received: by lbjn8 with SMTP id n8so1246363lbj.0 for ; Sun, 29 Apr 2012 08:34:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VO9s2nqx+5ACwhh7KAJvRY5BblkYax5mhxn49n2covY=; b=VeEvbNrDzzNJ6skrkvp0L/3b1F7jBT/+CjjNfaF3FnWs59tHL6VB2Pa/UzC3mCIric BSCGTm83pffK1Vb4rdL8EQjFOmd+woC/iGlwXxZvOoRgw8OrJVv6fdFxXT/njcQuDKdK UfRLkSBVzEpS8Yn4p7KIkrsUTq/L7TtElXK+6A3JeToY8kCL4fzO6gLKYW0VazuIEUnO 0KSCrmkDV2kUk6ppEW0eMAsCNpK0MCx+EP9OGgStRJnLvZSjPZSygjjso0qQS9tkX/4G PLOctpFPaREYNn7SUzB3o6AuM+vkjCICL+GvN3l6qsFLaTeUT9wplSk8+DYKWmSLzW8b VaSg== Received: by 10.152.146.129 with SMTP id tc1mr6620692lab.27.1335713672745; Sun, 29 Apr 2012 08:34:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.23.68 with HTTP; Sun, 29 Apr 2012 08:34:12 -0700 (PDT) In-Reply-To: <4F991CA5.8070503@redhat.com> References: <4F97BF9E.6070103@redhat.com> <4F991CA5.8070503@redhat.com> From: Gaash Hazan Date: Sun, 29 Apr 2012 15:34:00 -0000 Message-ID: Subject: Re: libffi & fork To: Andrew Haley Cc: libffi-discuss@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZr51aq6IykazN03lzT2KuvNRZDfDkajMW0Hxm9PRpP8/ba6pBd5BjTL/aaWGY+dl5zXTf X-IsSubscribed: yes Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org X-SW-Source: 2012/txt/msg00187.txt.bz2 Hi Andrew, Thanks for the detailed answer. I think I found the root cause of the problem. The libffi version that I use (3.0.5) contains a bug in closures.c:selinux_enabled_check() that incorrectly detected non-selinux systsem as selinux system. Because system is detected (incorrectly) as selinux dlmap() does not attempts to do mmap() for private anonymous block with write-exec protection. It reverts to the trick with two mmap()s on a tmp file. But trick does not with fork. If the system is detected (correctly) as non-selinux, then dlmp() would use anonymous write-exec mmap() and it would not use the trick. Hence the fork problem would not occurred. The selinux detected problem was fixed in https://github.com/atgreen/libffi/commit/eaf444eabc4c78703c0f98ac0197b1619c= 1b1bef#src/closures.c (closures.c line 149) Unfortunately Redhat 6.2 and 6.3-bets uses libffi 3.0.5 that has this probl= em. Regards, Gaash On Thu, Apr 26, 2012 at 1:00 PM, Andrew Haley wrote: > > On 04/25/2012 06:32 PM, Gaash Hazan wrote: > >> There is, as far as I can see, only one way to remedy this: allow > >> python to map anonymous memory with both write and execute permission. > >> Then it should work fine. > > > > I believe memory allocation is a service provided by the OS and not by > > the application or interpreter. > > The usual problem is a mechanism such as SELinux that is forbidding > Python from mmap()ing PROT_WRITE|PROT_EXEC . =A0If you label the > executable unconfined_execmem_exec_t it may work because then libffi > won't bother with all this multiple maps though a shared file > descriptor business. > > > Python does not provide memory allocation service to libffi. In this > > case libffi creates read-write-exec memory block using mmap to a tmp > > file. I guess the problem is common to libff users and it is not > > unique to python. > > It's special to Python because Python is the only common libffi client > that forks and then tries to use the closures. > > > libffi uses mmap with MAP_SHARED at libffi:closures.c:dlmap(). What > > was the reason for using MAP_SHARED =A0in the first place? > > > > I think MAP_PRIVATE would create the desired behavior of copy-on-write > > when forked. Would that be a proper fix? > > No, memory regions that are backed by a real file are always shared > between processes. =A0There is a single file descriptor that > references the block of memory that holds the closures. =A0The only > way you'll get it to work is to create a new file. > > Andrew.